OK, I have nessus 2.0.9 (all parts) built and running -- they compile clean
(no cast warnings) and run OK. Patches have been posted to bugzilla.
I have started looking at nessus 2.0.10a and see that some (not all) of the
problems addressed by the patches are in 2.0.10a. However, at least one of
these updates has not caused a problem for sparc/Solaris --
http://bugs.nessus.org/show_bug.cgi?id=739 -- I am not sure how to address
this particular problem in nessus without something in ./configure which
specifically says the system is linux-64bit or having a patch which is
applied to such systems (the current patch works OK on Fedora Core Linux i386
and x86_64 but I am not sure about other Linux systems let alone *BSD).
I am not sure what the right solution is but comments would be appreciated.
The AMD Opteron/Athlon64 processors is the first hardware which has
significant performance improvement when it is run in 64 bit mode ... double
the number of registers which the compiler can use. This means (to me) that
a lot of code can and will be ported to be 64 bit applications. Other
processors such as the Sparc and the PowerPC which are capable of dual mode
do not have this improvement (and may even have less performance besides
having larger pointers and code size). So, anyway, this is my incentive to
get nessus running on the AMD64 ... I believe that there is a future to it
(and so does Microsoft since they have a 64 bit windows in beta).
What I am looking for in the following are comments such as ... "this does not
make sense because ...", "this does make sense because ...", and/or "oops,
that does not work on the xxx systems since we do not have that
capability/feature/etc."
1. On the AMD64 pointers are 8 bytes and size_t is also 8 bytes. On the i386
pointers are 4 bytes and size_t is also 4 bytes. On both systems, the size
of int is 4 bytes and the size of long int is 8 bytes. Therefore, in
functions such as regex.c which do some strange things with pointers, making
some of the other variables be size_t rather than unsigned int gets rid of
the "cast" warning messages (about assignments between pointers and
variables). Questions:
. Will this work on other systems such as Solaris?
. Will this work on the AMD64 versions of *BSD?
2. I see that some of the printing of pointer values in debug messages have
been changed from "%d" to "%ld". I believe that the proper way to handle
printing pointers is to use "%p" which will do 8 byte pointers in a 64 bit
application and 4 byte pointers in a 32 bit application. Question:
. Is "%p" available on all the other systems?
3. At least on Linux with glibc, there is "%zd" which does something similar
for size_t variables ... does 8 bytes in 64 bit applications and 4 bytes in
32 bit applications. To me, this should be preferable to using "%ld"
everywhere ... it is more correct. Question:
. Is "%zd" available on other systems?
4. For the most part, nessus uses prototypes to make sure that parameters are
properly passed. There are some cases (e.g., bpf_datalink in
libnessus/ids_send.c) where there is no prototype. Proposed: prototypes
should be defined/used for all functions.
Ask additional ideas/questions occur to me, I will post additional messages.
I look forward to comments.
--
Gene Czarcinski
(no cast warnings) and run OK. Patches have been posted to bugzilla.
I have started looking at nessus 2.0.10a and see that some (not all) of the
problems addressed by the patches are in 2.0.10a. However, at least one of
these updates has not caused a problem for sparc/Solaris --
http://bugs.nessus.org/show_bug.cgi?id=739 -- I am not sure how to address
this particular problem in nessus without something in ./configure which
specifically says the system is linux-64bit or having a patch which is
applied to such systems (the current patch works OK on Fedora Core Linux i386
and x86_64 but I am not sure about other Linux systems let alone *BSD).
I am not sure what the right solution is but comments would be appreciated.
The AMD Opteron/Athlon64 processors is the first hardware which has
significant performance improvement when it is run in 64 bit mode ... double
the number of registers which the compiler can use. This means (to me) that
a lot of code can and will be ported to be 64 bit applications. Other
processors such as the Sparc and the PowerPC which are capable of dual mode
do not have this improvement (and may even have less performance besides
having larger pointers and code size). So, anyway, this is my incentive to
get nessus running on the AMD64 ... I believe that there is a future to it
(and so does Microsoft since they have a 64 bit windows in beta).
What I am looking for in the following are comments such as ... "this does not
make sense because ...", "this does make sense because ...", and/or "oops,
that does not work on the xxx systems since we do not have that
capability/feature/etc."
1. On the AMD64 pointers are 8 bytes and size_t is also 8 bytes. On the i386
pointers are 4 bytes and size_t is also 4 bytes. On both systems, the size
of int is 4 bytes and the size of long int is 8 bytes. Therefore, in
functions such as regex.c which do some strange things with pointers, making
some of the other variables be size_t rather than unsigned int gets rid of
the "cast" warning messages (about assignments between pointers and
variables). Questions:
. Will this work on other systems such as Solaris?
. Will this work on the AMD64 versions of *BSD?
2. I see that some of the printing of pointer values in debug messages have
been changed from "%d" to "%ld". I believe that the proper way to handle
printing pointers is to use "%p" which will do 8 byte pointers in a 64 bit
application and 4 byte pointers in a 32 bit application. Question:
. Is "%p" available on all the other systems?
3. At least on Linux with glibc, there is "%zd" which does something similar
for size_t variables ... does 8 bytes in 64 bit applications and 4 bytes in
32 bit applications. To me, this should be preferable to using "%ld"
everywhere ... it is more correct. Question:
. Is "%zd" available on other systems?
4. For the most part, nessus uses prototypes to make sure that parameters are
properly passed. There are some cases (e.g., bpf_datalink in
libnessus/ids_send.c) where there is no prototype. Proposed: prototypes
should be defined/used for all functions.
Ask additional ideas/questions occur to me, I will post additional messages.
I look forward to comments.
--
Gene Czarcinski