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

List:       nmap-dev
Subject:    Re: nmap 3.3+V-2.99
From:       "Jay Freeman \(saurik\)" <saurik () saurik ! com>
Date:       2003-09-05 0:53:06
[Download RAW message or body]

Gisle:

Wouldn't the more correct approach be to create a better interface? One that
returns a void * that must be returned when the mmap is to be destroyed?
This entire issue is coming up because the Unix mmap() semantics are being
required when they aren't sufficient for all platforms. Making it a stack
still requires all memory mappings to be done in a nested fashion, which
definitely isn't a requirement of any underlying API.

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

----- Original Message -----
From: "Gisle Vanem" <giva@bgnett.no>
To: "Fyodor" <fyodor@insecure.org>
Cc: <nmap-dev@insecure.org>
Sent: Thursday, September 04, 2003 6:54 PM
Subject: Re: nmap 3.3+V-2.99


> "Fyodor" <fyodor@insecure.org> said:
>
> > Is there a good reason for not bailing if gmap is NULL?  The point is
> > to detect cases where the code munmap's a file that it hasn't even
> > mmap'd (or if it munmaps a file twice).  Other than these cases of API
> > misuse, does the (gmap == 0) check cause any problems?
>
> You're correct. That patch isn't needed. But IMHO, we should try to
> make a stack of mapped files for Win32.
>
> --gv>
>


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help@insecure.org . List run by ezmlm-idx (www.ezmlm.org).


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