www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal: c_int

reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Problem:

On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
On 64-bit Unix systems "int" is defined as "std.stdint.int64_t" 
(64-bit mode) or "std.stdint.int32_t" (32-bit mode).

All C bindings would have to write their own kludges to evade those
problems. The current problem is that those kludges can't be written in D.
No, "version(X86_64)" isn't sufficent.

The situation is the same for "unsigned int", "long", "unsigned long",
"long long" and "unsigned long long".

Implementing at least on of the suggestions below would allow a "pure D"
soultion.

Suggestion: 1/3
Define size_t and ptrdiff_t as true D types directly in the compiler
and add the following snipplet to std.stdint:

 version(Win32){
     alias int32_t c_int;
 }else version(Win64){
     alias int32_t c_int;
 }else version(Windows){
     static assert(0);
 }else{
     alias ptrdiff_t c_int;
 }

Suggestion: 2/3 Define D_BITS_PER_C_INT_32 or D_BITS_PER_C_INT_64 as predefined versions in the compiler and add the following to std.stdint:
 version(D_BITS_PER_C_INT_32){
     alias int32_t c_int;
 }else version(D_BITS_PER_C_INT_64){
     alias int64_t c_int;
 }else{
     static assert(0);
 }

Suggestion: 3/3 Enhance "version" so, that a version can have a numerical value and define "version[D_BITS_PER_C_INT=32" or "version[D_BITS_PER_C_INT=64" inside the compiler and add the following to std.stdint:
 version(D_BITS_PER_C_INT == 32){
      alias int32_t c_int;
 }version(D_BITS_PER_C_INT == 64){
      alias int64_t c_int;
 }else{
      static assert(0);
 }

Suggestion 3 seems to be the most powerfull one and might solve other common implementation problems too. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDvpqf3w+/yD4P9tIRAtAtAKC4Ei69tNmg+57MND75XAlHI6RJ/gCdEUKO BwdJtEAyhsz0zsi4S3de9pc= =KGxd -----END PGP SIGNATURE-----
Jan 06 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Thomas Kuehne wrote:

 On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
 On 64-bit Unix systems "int" is defined as "std.stdint.int64_t" 
 (64-bit mode) or "std.stdint.int32_t" (32-bit mode).

For what it is worth, on PPC64 "int" is 32 bits and "long" is 64 bits. I believe the same is true in the AMD64 arch ABI for Linux, as well ? (I think the programming model is called LP64 ?) See http://developer.apple.com/macosx/64bit.html This still means that ints can no longer hold pointers, for instance... (nor can it hold the length of a pointer, need to use size_t for that) Side note: I think it would be nice if there was a short D name to use for "largest hardware implemented integer size", for loops and such ? (since "int" is always 32 bits and "size_t" is hard to pronounce) Like the current variable-size "real" type for floating point ? Too bad that the natural name for such a thing is already taken... Then again I haven't benchmarked, maybe 32-bit is just as "fast" ? Just thinking about something that would be 32 bits on a 32-bit machine and 64 bits on a 64-bit machine (i.e. in 64 bit mode) ? --anders PS. Another fun change is that "bool" is now back at 1 byte, from 4. (change in the Mac OS X ppc ABI that was, from 32-bit to 64-bit) On the X86->X64 side, one noteworthy change is that "long double" is now 16 bytes in size instead of 12 (but still *using* just 10)
Jan 06 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Anders F Björklund wrote:
 Thomas Kuehne wrote:
 
 On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
 On 64-bit Unix systems "int" is defined as "std.stdint.int64_t" 
 (64-bit mode) or "std.stdint.int32_t" (32-bit mode).

For what it is worth, on PPC64 "int" is 32 bits and "long" is 64 bits. I believe the same is true in the AMD64 arch ABI for Linux, as well ?

Hrm... I think that's actually correct. I don't know of any platforms offhand where the size of 'int' are changing--it was 'long' that was the issue. This should improve things considerably, though it will mean more work modifying the headers as a search-replace isn't possible. I'm of a mind to just create an alias for each size type to address this: c_int, c_long, etc. I wish I'd done that at the outset. Sean
Jan 06 2006
prev sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Anders F Björklund schrieb am 2006-01-06:
 Thomas Kuehne wrote:

 On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
 On 64-bit Unix systems "int" is defined as "std.stdint.int64_t" 
 (64-bit mode) or "std.stdint.int32_t" (32-bit mode).

For what it is worth, on PPC64 "int" is 32 bits and "long" is 64 bits. I believe the same is true in the AMD64 arch ABI for Linux, as well ? (I think the programming model is called LP64 ?) See http://developer.apple.com/macosx/64bit.html

Right, please replace "int" with "long" in my posting.
 Side note:
 I think it would be nice if there was a short D name to use for
 "largest hardware implemented integer size", for loops and such ?
 (since "int" is always 32 bits and "size_t" is hard to pronounce)

 Like the current variable-size "real" type for floating point ?

Sounds usefull.
      On the X86->X64 side, one noteworthy change is that "long double"
      is now 16 bytes in size instead of 12 (but still *using* just 10)

Don't tell me they wasted 3/8 of the storage to be compatible with old binaries and have a decent alignment... Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDvt7v3w+/yD4P9tIRAhruAJ9hIb8RKRLKMzGQ10/Q1MJwk9k+3ACguGx5 /+t2u3YABSTLQLSyMmtZddc= =01d7 -----END PGP SIGNATURE-----
Jan 06 2006
next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Thomas Kuehne wrote:

     On the X86->X64 side, one noteworthy change is that "long double"
     is now 16 bytes in size instead of 12 (but still *using* just 10)

Don't tell me they wasted 3/8 of the storage to be compatible with old binaries and have a decent alignment...

You got it... 2 bytes "wasted" on X86, and 6 bytes on X64. Read about it in: http://gcc.fyxm.net/summit/2003/Porting%20to%2064%20bit.pdf --anders
Jan 06 2006
prev sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Thomas Kuehne wrote:

I think it would be nice if there was a short D name to use for
"largest hardware implemented integer size", for loops and such ?
(since "int" is always 32 bits and "size_t" is hard to pronounce)

Like the current variable-size "real" type for floating point ?

Sounds usefull.

Wonder if it makes a difference, though ? It doesn't on PowerPC, since the PPC is a 64-bit architecture with a 32-bit subset... Perhaps it does on X86, but I would imagine that being able to quickly handle 32-bit integers would be a pretty high priority ? --anders
Jan 06 2006
prev sibling parent Sean Kelly <sean f4.ca> writes:
Thomas Kuehne wrote:
 
 On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
 On 64-bit Unix systems "int" is defined as "std.stdint.int64_t" 
 (64-bit mode) or "std.stdint.int32_t" (32-bit mode).
 
 All C bindings would have to write their own kludges to evade those
 problems. The current problem is that those kludges can't be written in D.

*sigh* I'd forgotten about this. I'd be happy to update the C headers in Ares with whatever method seems appropriate. Sean
Jan 06 2006