printing size_t variables

2006-09-02 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Should we have a gnulib module for *printf that allows us to use the POSIX-mandated printf("%zu", (size_t)1) modifier for size_t variables? Or what is the current recommended practice for printing size_t? - -- Life is short - so eat dessert first! E

Re: coreutils-6.0 on platforms without fchdir

2006-09-02 Thread Bruno Haible
Paul Eggert wrote: > On platforms lacking fchdir, > put a wrapper around 'open' so that we can keep track of which file > descriptors correspond to directories. The 'open' wrapper puts the > name of the opened directory into a hash table. (The name must be > absolute, so 'open' may need to do the

Re: printing size_t variables

2006-09-02 Thread Oskar Liljeblad
On Saturday, September 02, 2006 at 06:26, Eric Blake wrote: > > Should we have a gnulib module for *printf that allows us to use the > POSIX-mandated printf("%zu", (size_t)1) modifier for size_t variables? Or > what is the current recommended practice for printing size_t? Or one could make a mod

Re: [bug-gnulib] printing size_t variables

2006-09-02 Thread Bruno Haible
Eric Blake wrote: > Should we have a gnulib module for *printf that allows us to use the > POSIX-mandated printf("%zu", (size_t)1) modifier for size_t variables? Or > what is the current recommended practice for printing size_t? libintl has a POSIX compliant printf, declared in , for platforms wh

Re: printing size_t variables

2006-09-02 Thread Mark D. Baushke
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Blake <[EMAIL PROTECTED]> writes: > Should we have a gnulib module for *printf that > allows us to use the POSIX-mandated > printf("%zu", (size_t)1) modifier for size_t > variables? Or what is the current recommended > practice for printing size_

Re: printing size_t variables

2006-09-02 Thread Ben Pfaff
"Mark D. Baushke" <[EMAIL PROTECTED]> writes: [printf] > I would not mind seeing both the j and z modifiers > generally implemented. However, as Bruno mentions, > this would likely be a fair amount of overhead just > for those few format characters. I think casting is > good enough for now. z an