Re: Long long int's and sprintf

From: Mike Stilson (mike@c746148-a.ehlls1.pa.home.com)
Date: 06/17/01


On Sun, Jun 17, 2001 at 02:58:47AM -0400, Cris Jacobin came up with this idea:
>         What is the difference between using %lu, %llu and the strtoull
> function to write out the bitvector?  I'm currently using llu  as was
> initially suggested.  Any reason beyond mere preference to change?

%lu will only give you a 32 bit integer.
%llu, %Lu, etc are fore 64 bits.

as we're discussing, there's some issues with versions of gcc and
glibc and the support of strtoull().

The nutshell solution to strtoull() not defining on your system is
(afaict) one of 3 things:
1: use the full version of the conversion:
dest_var = strtoull((char *)src_var, char terminator, int base)

2: be very careful when/where you define (check stdlib.h for specifics)
   __USE_ISOC9X

3: handle the data yourslef, stuff it into a string, and sscanf(str,"%Lu",&var);

>
>         Overall, been a quite helpful thread.  Now have 64 bits for
> everything, with little effort.  Not sure I'll need 64 exit flags
> however ;)  This was a topic that was a gaping hole in the archives so
> bound to be of help to many.  Thanks to everyone who contributed,
> especially the ascii conversion routines.

I didn't really bother reading the docs for that too much, so I don't know
how bad they might be lacking in that area, but rather than wasting tons of
emails discussing the technical guts of glibc and pals, I'd prefer to take
it private and post a summary.

ps: you're welcome for the modified flag conversions.

Careful though.  Next I'll be telling you how to run the mud off sql
databases while handling the data sizes. (Only shops & zones left to go...
and an intense lesson on fork() and friends)

-mike

--
   +---------------------------------------------------------------+
   | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
   | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
   +---------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/05/01 PST