Nmap Development mailing list archives

Re: [NSE patch] patch for pack/unpack to use platform independant types


From: doug () hcsw org
Date: Sun, 17 Aug 2008 13:29:44 -0700

On Sun, Aug 17, 2008 at 10:38:26AM +0200 or thereabouts, Sven Klemm wrote:
Fyodor wrote:
| Have you researched whether "signed long" is 32 bits on all Windows
| platforms (including 64-bit platforms) and that "signed long long" is
| always 64 bits?  Have you researched whether Windows provides type
| definitions with a more explicit bitwidth guarantee?

According to MSDN those types do not differ on 32-bit vs 64-bit. But
Microsoft C++ also has __int8, __int16, __int32 and __int64. Using
those types is probably better.

Like Sven said, int and long are 32 bits on both win32 and win64 and
long long is 64 bits on win64. There is some handy jargon for this.
I'm not sure who came up with this terminology, probably the X/Open
or POSIX commitees:


Datatype        LP64    ILP64   LLP64   ILP32   LP32
----------------------------------------------------
char            8       8       8       8       8
short           16      16      16      16      16
_int32                  32                      
int             32      64      32      32      16
long            64      64      32      32      32
long long                       64              
pointer         64      64      64      32      32


win3.1 and Macintosh systems 7-9: LP32
unix32 and win32: ILP32
unix64: LP64
win64: LLP64


Read this for details on why LP64 is Right for unix64:

http://www.unix.org/version2/whatsnew/lp64_wp.html

And this for why LLP64 is Right for win64:

http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

Note: Also, many windows APIs use something called a DWORD which
is always an unsigned 32 bit int and actually has nothing to do
with your word size.

Doug

Attachment: signature.asc
Description: Digital signature


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

Current thread: