[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nessus-devel
Subject:    [Nessus-devel] Re: Questions
From:       Renaud Deraison <deraison () nessus ! org>
Date:       2004-01-26 14:41:01
Message-ID: 20040126144101.GF633 () nessus ! org
[Download RAW message or body]

On Mon, Jan 26, 2004 at 07:41:46AM -0500, Gene C. wrote:
> 1. At least one of the updates [sizeof(ifmap)] cases problems on Solaris and 
> possibly other systems too.  This will need more work to make things work 
> properly on all systems.


I'll work on the Solaris issue today - expect a fix in CVS within a
couple of hours.

> 2. While the rlimit patch I submitted works OK, the setting of memory limits 
> needs to be a runtime option in /etc/nessus/nessusd.conf.

On my roadmap.

> 3.  Many/most of the lack of prototypes from the SUSE and other patches have 
> been incorporated in 2.0.10a.  I have found a problem on the amd64 with 
> memmem() where the prototype from <string.h> still causes cast problems but a 
> locally defined prototype (using the definition in the man page) does not.  
> This needs more investigation by me.


memmem() is not defined on all platforms, so the patch you submitted
would actually break stuff on other systems.

> 4.  You have rejected most of the porting/cast fixes developed by SUSE and 
> this was the CORRECT thing to do.  These patches are just plain wrong in what 
> they do.

Yes. I hate linux-isms in the code.

> 2. For pointer related variables [and function parameters and returned values] 
> which will/may hold a pointer, we need something that will size to 4 bytes on 
> IA32 and to 8 bytes on the amd64 and other 64 bit architectures.  It would be 
> very nice to continue to size variables which truly only need 32 bits as 4 
> byte variables.  The obvious (to me) solutions is to use long and unsigned 
> long (and size_t and ssize_t in nessus for MS Windows [MS recommended 
> solution]).

Every pointer is (or _should be_, otherwise it's a bug) stored as a
void *, which is the right thing to do and solve the issue.


[..]
> While I regret that pointers were stored into int variables


No they were not, it's the other way thru - some int variables are
stored as a void*, but that should not cause any problem. For the sack
of cleanness, we could add a arg_get_int() instead of arg_get_value()
which does the cast - and that would greatly reduce the number warnings
you get at compilation time, but that would not solve anything more than
the current situation.


				-- Renaud
_______________________________________________
Nessus-devel mailing list
Nessus-devel@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus-devel
[prev in list] [next in list] [prev in thread] [next in thread]