RE: [Dev-C++] Can I handle 64 bits with unsigned long long int ?

[Ioannis V. <iv...@at...>]

> -----Original Message-----
> From: dev...@li...=20
> [mailto:dev...@li...] On Behalf=20
> Of Daniel K. O.
> Sent: Sunday, April 06, 2003 9:36 PM
> To: 'Dev-C++ -Users-List'
> Subject: RES: [Dev-C++] Can I handle 64 bits with unsigned=20
> long long int ?
>=20
>=20
>=20
>=20
>=20
>  >  Obviously MINGW's unsigned long long isn't 64 bit or=20
> there is serious
>  >  compiler bug. An equivalent code:
>=20
>=20
>=20
> Ok, let's try again... You have:
>=20
> unsigned long long i =3D ULLONG_MAX;
>=20
> So you have i =3D 0xFFFFFFFFFFFFFFFF;


Why?


> And sizeof (i) =3D 8;


Irrelevant. It may have padding bits.




> Now, you printf("%llu", i); printf provided on MSVCRT.DLL=20
> should "eat" 8
> bytes from the stack (0xFFFFFFFFFFFFFFFF), to print the=20
> unsigned long long.
> But it doesn't. I thinks that %llu is for a 4 bytes int, and=20
> only prints the
> first word of the unsigned long long (you can put another=20
> "%llu", if you
> want to see the other half :P=20



%llu is for the type unsigned long long. Failure to print the whole =
range of
the unsigned long long values would be a compiler defect.



> ). This bug is not on MinGW, but on
> MSVCRT.DLL, where the printf is implemented. While MinGW=20
> keeps using the
> runtime lib from MS, or MS doesn't update its C Runtime=20
> library, you'll have
> to use "%I64d", "%I64u", "%I64x", etc.



I have no idea of the compiler internals. It may be a bug of the dll you
mention, I do not know. Regarding the specifiers you are mentioning =
above,
as far as I know are not part of the standard.



>=20
>=20
> Again, here is the link about this issue:
>=20
> "printf function does not support long long"
> [all-in-one-line]
> http://sf.net/tracker/?func=3Ddetail&aid=3D661165&group_id=3D2435&at
id=3D102435
[/all-in-one-line]



Ok. Another portable approach would be the use of size_t, e.g.:


#include <stdio.h>
#include <stddef.h>


int main(void)
{
  printf ("Maximum value of size_t: %sz\n", (size_t)-1);

  getchar();

}


Unfortunately it crashes to me. It seems MINGW has a long way to go
regarding C99 stability.

Also SIZE_MAX seems to not exist in MINGW implementation...




Ioannis Vranos
=20
* Programming pages: http://www.noicys.freeurl.com
* Alternative URL: http://run.to/noicys


Anti-racism movement: http://www.positive-youthfoundation.org
Iraq Peace Pledge: http://www.peacepledge.org