www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - ulong is not 64 bit long?

reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Hi all,

  Is ulong 64bit or not?
  I'm SuSE 10.0 on a 32bit machine. On this page
[http://www.digitalmars.com/d/type.html] we can see that ulong should be
64bit long.
  With gcc we have the unsigned long long which, although the machine might
not be true 64bit, the data type is still 64 bit.
  i.e. gcc compiles correctly on a 64bit machine and fakes on a 32bit
machine.
  Why is ulong.max only 2^32-1 ?? Is this a bug?
  Thanks!


Best Regards,
Tiago Gasiba

-- 
Tiago Gasiba (MSc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
Oct 17 2005
parent reply Don Clugston <dac nospam.com.au> writes:
Tiago Gasiba wrote:

 Hi all,
 
   Is ulong 64bit or not?
   I'm SuSE 10.0 on a 32bit machine. On this page
 [http://www.digitalmars.com/d/type.html] we can see that ulong should be
 64bit long.
   With gcc we have the unsigned long long which, although the machine might
 not be true 64bit, the data type is still 64 bit.
   i.e. gcc compiles correctly on a 64bit machine and fakes on a 32bit
 machine.
   Why is ulong.max only 2^32-1 ?? Is this a bug?
   Thanks!


ulong is definitely 64 bits, it's faked on 32 bit CPUs.
ulong.max == 2^64-1 on DMD - WinXP.
Are you using DMD-Linux or DMC ?
Oct 17 2005
parent reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Hi!

  I'm using dmd on Linux with "gcc (GCC) 4.0.2 20050901 (prerelease)(SUSE
Linux)" and D version is Digital Mars D Compiler v0.136


  Here it goes:

test.d:
------- code -------
import std.c.stdio;
import std.c.stdlib;

int main( ){
  printf("%lu\n",ulong.max);
  return 0;
}
------- code -------

dmd -w test.d
./test
4294967295   (answer = 2^32-1 !!!)

Even worse is this:

------- code -------
import std.c.stdio;
import std.c.stdlib;

int main( ){
  ulong X = 0xffff000000000000L;

  printf("%lu\n",X);
  return 0;
}
------- code -------

dmd test.d - no compiler errors
./test
0  (answer = 0!!!)


Thanks,

Tiago

Don Clugston wrote:


 Tiago Gasiba wrote:

 Hi all,
 
   Is ulong 64bit or not?
   I'm SuSE 10.0 on a 32bit machine. On this page
 [http://www.digitalmars.com/d/type.html] we can see that ulong should be
 64bit long.
   With gcc we have the unsigned long long which, although the machine
   might
 not be true 64bit, the data type is still 64 bit.
   i.e. gcc compiles correctly on a 64bit machine and fakes on a 32bit
 machine.
   Why is ulong.max only 2^32-1 ?? Is this a bug?
   Thanks!


 
 ulong is definitely 64 bits, it's faked on 32 bit CPUs.
 ulong.max == 2^64-1 on DMD - WinXP.
 Are you using DMD-Linux or DMC ?


-- 
Tiago Gasiba (MSc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
Oct 17 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
Use %llu to print a C "long long", which is the equivalent of a D "long".
%lu will print a C "long", which is only 32 bits. Or, use
std.stdio.writefln(X).
Oct 17 2005
next sibling parent Tiago Gasiba <Tiago_member pathlink.com> writes:
So, everything works fine now, even printf("%llu\n",ulong.max), of course!
Or, better said, it allways worked fine :) ...

Thanks!

Tiago Gasiba (MSc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
Oct 17 2005
prev sibling next sibling parent reply Oskar Linde <Oskar_member pathlink.com> writes:
In article <dj0g9l$elk$1 digitaldaemon.com>, Walter Bright says...

Use %llu to print a C "long long", which is the equivalent of a D "long".
%lu will print a C "long", which is only 32 bits. Or, use
std.stdio.writefln(X).


Isn't it time to replace printf by writef et.al. as default imported symbols, or
remove the default import of printf?

/Oskar
Oct 17 2005
parent reply JT <jtd514 ameritech.net> writes:
No. That would be a Very Bad Idea.


Oskar Linde wrote:

 
 Isn't it time to replace printf by writef et.al. as default imported symbols,
or
 remove the default import of printf?
 
 /Oskar
Oct 17 2005
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
JT wrote:

 No. That would be a Very Bad Idea.
 


Why? I think it would be a great idea.


 
 Oskar Linde wrote:
 

 Isn't it time to replace printf by writef et.al. as default imported 
 symbols, or
 remove the default import of printf?

 /Oskar
Oct 17 2005
next sibling parent reply JT <jtd514 ameritech.net> writes:
Because they are very different creatures. Just because you have no need 
for printf doesnt mean you should take it away from me. You are 
basically talking about 'censoring' portions of the standard c 
libraries. huh?




Ivan Senji wrote:

 JT wrote:
 

 No. That would be a Very Bad Idea.


 
 Why? I think it would be a great idea.
 

 Oskar Linde wrote:


 Isn't it time to replace printf by writef et.al. as default imported 
 symbols, or
 remove the default import of printf?

 /Oskar
Oct 17 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
No, I think he just means making it so printf has to be imported (like 
every other C function) which is not the case currently (since it is 
automatically imported/defined in object.d.)

-[Unknown]



 Because they are very different creatures. Just because you have no need 
 for printf doesnt mean you should take it away from me. You are 
 basically talking about 'censoring' portions of the standard c 
 libraries. huh?
Oct 17 2005
parent reply JT <jtd514 ameritech.net> writes:
Oh my mistake, I thought he was talking about just replacing the printf 
with a writef. Sorry. I think I need sleep. heh


Unknown W. Brackets wrote:

 No, I think he just means making it so printf has to be imported (like 
 every other C function) which is not the case currently (since it is 
 automatically imported/defined in object.d.)
 
 -[Unknown]
 
 

 Because they are very different creatures. Just because you have no 
 need for printf doesnt mean you should take it away from me. You are 
 basically talking about 'censoring' portions of the standard c 
 libraries. huh?
Oct 17 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
JT wrote:

 Oh my mistake, I thought he was talking about just replacing the printf 
 with a writef. Sorry. I think I need sleep. heh
 


No problem :) The printf has it's place and i agree someone might need 
it (although in my eyes printf can not compete with writef), but default 
importing it shouldn't be done.


 
 Unknown W. Brackets wrote:
 

 No, I think he just means making it so printf has to be imported (like 
 every other C function) which is not the case currently (since it is 
 automatically imported/defined in object.d.)

 -[Unknown]



 Because they are very different creatures. Just because you have no 
 need for printf doesnt mean you should take it away from me. You are 
 basically talking about 'censoring' portions of the standard c 
 libraries. huh?
Oct 17 2005
prev sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
news:dj0t1p$pq0$1 digitaldaemon.com...

 JT wrote:

 No. That would be a Very Bad Idea.


 Why? I think it would be a great idea.


I agree

 Oskar Linde wrote:


 Isn't it time to replace printf by writef et.al. as default imported 
 symbols, or
 remove the default import of printf?

 /Oskar
Oct 17 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <dj0g9l$elk$1 digitaldaemon.com>, Walter Bright says...

Use %llu to print a C "long long", which is the equivalent of a D "long".
%lu will print a C "long", which is only 32 bits. Or, use
std.stdio.writefln(X).


For those who insist on using printf, the C standard does supply a host of
pre-done format strings in inttypes.h in an attempt to avoid these mistakes.
Probably more useful as a reference than for actual use in a D project, but I've
just added them to Ares for the sake of completeness:

http://svn.dsource.org/projects/ares/trunk/src/ares/std/c/inttypes.d


Sean
Oct 18 2005
parent reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Sean Kelly hat geschrieben:


 In article <dj0g9l$elk$1 digitaldaemon.com>, Walter Bright says...

Use %llu to print a C "long long", which is the equivalent of a D "long".
%lu will print a C "long", which is only 32 bits. Or, use
std.stdio.writefln(X).


 
 For those who insist on using printf, the C standard does supply a host of
 pre-done format strings in inttypes.h in an attempt to avoid these
 mistakes. Probably more useful as a reference than for actual use in a D
 project, but I've just added them to Ares for the sake of completeness:
 
 http://svn.dsource.org/projects/ares/trunk/src/ares/std/c/inttypes.d
 
 
 Sean


What got me confused in the first place is the fact that the "long long" in
C is simply "long" in D, and I forgot for a second the fact that the D
printf is a wrapper to the C printf, i.e. this function was not rewritten
in D to match the new data types...
Shame on me! :)

Best,
Tiago

-- 
Tiago Gasiba (MSc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
Oct 19 2005
parent Sean Kelly <sean f4.ca> writes:
In article <dj4td4$15lu$1 digitaldaemon.com>, Tiago Gasiba says...

What got me confused in the first place is the fact that the "long long" in
C is simply "long" in D, and I forgot for a second the fact that the D
printf is a wrapper to the C printf, i.e. this function was not rewritten
in D to match the new data types...
Shame on me! :)


It confuses me too sometimes :)  What helps me remember is that I consider 'int'
to be the type in C whose size is most likely to vary, so the standard
size-based progression is: char, short, long, long long.  It's just too bad that
'long long' has such an unwieldy name.


Sean
Oct 19 2005