Eric Blake | 1 Oct 01:05 2005
Picon
Picon

Re: printf (_("...%zu..."), X) where X is of type size_t

> >> > +/* Determine a printf conversion specifier that is appropriate for size_t.
> >> > +   Ideally, we'd just use the c99-specified `z' length modifier, defining
> >> > +   PRI_z to "zu", but that's not portable.  */
> >> ...
> >> I thought about doing that a while ago but gave it up because it
> >> appears that this sort of approach will run afoul of gettext.
> > ...
> > Maybe it's time that we provide a gnulib module for printf 
> 
> Personally I'd rather not head down that path.  printf is the biggest
> cesspool in the C library, and lots of things that C likes to sweep
> under the rug finds its way into printf somehow: floating-point
> accuracy, cancellation points, multibyte encoding errors, signal
> handling, storage allocation, wrong-sized types for the job, etc.,
> etc.  I suppose we could drag glibc's printf into gnulib, but I
> wouldn't envy the task of doing that, or maintaining the result.

When I wrote my suggestion, I was thinking more along the
lines of a thin wrapper, whose sole job in life is to translate the
format string into something that the system's vprintf can already
handle, without ever unwrapping the va_args itself.  For that
matter, since the translation does not need to know what the
va_args are, maybe my suggestion is better written like this:

printf (printf_format (_("The size is %zu.")), size);

where we only provide printf_format, and its job is
to turn the "%z" into "%l" or "%ll" in the translation,
as appropriate.

(Continue reading)

Ben Pfaff | 1 Oct 01:00 2005
Picon

Re: printf (_("...%zu..."), X) where X is of type size_t

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

> If 'size' is of type size_t, then where I was suggesting this:
>
>      unsigned long int s = size;
>      printf (_("The size is %lu.\n"), size);
>
> the gettext manual suggests something like this instead:
>
>      char buf[INT_BUFSIZE_BOUND (size_t)];
>      sprintf (buf, "%" PRIuSIZE, size);
>      printf (_("The size is %s.\n"), buf1);
>
> where we define PRIuSIZE in system.h.  But this is even more awkward.

I have an idea, but I don't know whether it's reasonable.  How
about a function that does a makes a copy of a format string, in
the process doing a textual search-and-replace of %zu, etc. by
the local system's appropriate size modifier?  Then the above
would become something like:

        printf (fix_sizes (_("The size is %zu.\n")), size);

We'd want to write an Autoconf test for whether `z' and friends
are supported so that fix_sizes could be stubbed out if it was
unneeded, e.g.

        #ifdef HAS_C99_PRINTF
        #define fix_sizes(FORMAT) (FORMAT)
        #endif
(Continue reading)

Paul Eggert | 1 Oct 06:40 2005

Re: printf (_("...%zu..."), X) where X is of type size_t

ericblake <at> comcast.net (Eric Blake) writes:

> When I wrote my suggestion, I was thinking more along the
> lines of a thin wrapper, whose sole job in life is to translate the
> format string into something that the system's vprintf can already
> handle, without ever unwrapping the va_args itself.

You might run out of memory generating the translated format string.
That wouldn't be a nice thing to do (particularly if the message
you're trying to print is "can't allocate 230 bytes" :-).
James Youngman | 1 Oct 08:16 2005

Re: printf (_("...%zu..."), X) where X is of type size_t

On Fri, Sep 30, 2005 at 03:45:56PM -0700, Paul Eggert wrote:

> If 'size' is of type size_t, then where I was suggesting this:
> 
>      unsigned long int s = size;
>      printf (_("The size is %lu.\n"), size);

Am I mistaken, or is it the case that the C99 standard allows size_t
to be wider than unsigned long?    (e.g. unsigned long long)

James.
Paul Eggert | 1 Oct 08:18 2005

Re: printf (_("...%zu..."), X) where X is of type size_t

jay <at> excession.spiral-arm.org (James Youngman) writes:

> Am I mistaken, or is it the case that the C99 standard allows size_t
> to be wider than unsigned long?

You are not mistaken.  However, for gnulib the GNU coding standards
trump that.  They say:

   ... don't make any effort to cater to the possibility that
   'long' will be smaller than predefined types like 'size_t'.
   For example, the following code is ok:

     printf ("size = %lu\n", (unsigned long) sizeof array);
     printf ("diff = %ld\n", (long) (pointer2 - pointer1));

   1989 Standard C requires this to work, and we know of only one
   counterexample: 64-bit programs on Microsoft Windows IA-64.  We will
   leave it to those who want to port GNU programs to that environment
   to figure out how to do it.

   Predefined file-size types like 'off_t' are an exception: they are
   longer than 'long' on many platforms, so code like the above won't
   work with them.  One way to print an 'off_t' value portably is to
   print its digits yourself, one by one.

POSIX 1003.1-2001 also requires support for the assumption that size_t
is no wider than long int (sorry, can't cite chapter and verse
offhand).
Sergey Poznyakoff | 1 Oct 12:50 2005
Picon

Re: printf (_("...%zu..."), X) where X is of type size_t

Paul Eggert <eggert <at> CS.UCLA.EDU> wrote:

> Perhaps GNU extensions PRIoSIZE, PRIuSIZE, PRIxSIZE, PRIXSIZE could be
> added to GNU gettext.  That would mean we could write this instead:
> 
>      printf (_("The size is %"PRIuSIZE".\n"), size);

It would be nice. However, I doubt if it is possible: the string within
_() will be expanded by preprocessor and glued together by cc itself,
which means it will result in different literal strings on different
machines. Gettext will have no means of knowing how exactly is PRIuSIZE
expanded, so it will not be able to match the msgid.

Regards,
Sergey
Jim Meyering | 1 Oct 10:20 2005
Picon

Re: coreutils-5.90 build feedback

Thanks a lot!

"Nelson H. F. Beebe" <beebe <at> math.utah.edu> wrote:
> The coreutils-5.90 builds and installations went pretty smoothly,
> except for these:
>
> On Mac OS X:
>
>	expected actual differ: char 553, line 20
>	20d19
>	< f
>	21a21
>	> f
>	FAIL: basic
>	./deref: skipping this test; your system doesn't support changing
>	the owner or group of a symbolic link.

Would you please do this:

  env DEBUG=yes VERBOSE=yes make check -C tests/chmod TESTS=basic > log 2>&1

and then send the contents of `log'?

> On Solaris 7 with native cc:
>
> 	cc  -I/usr/local/include  -R/usr/local/lib -L/usr/local/lib -o pinky  pinky.o ../lib/libcoreutils.a
> 	/usr/local/lib/libintl.so /usr/local/lib/libiconv.so -lc -R/usr/local/lib
../lib/libcoreutils.a -lnsl
>
> 	Undefined			first referenced
(Continue reading)

Oskar Liljeblad | 1 Oct 10:51 2005
Picon

Re: printf (_("...%zu..."), X) where X is of type size_t

On Saturday, October 01, 2005 at 10:45, Sergey Poznyakoff wrote:
> 
> > Perhaps GNU extensions PRIoSIZE, PRIuSIZE, PRIxSIZE, PRIXSIZE could be
> > added to GNU gettext.  That would mean we could write this instead:
> > 
> >      printf (_("The size is %"PRIuSIZE".\n"), size);
> 
> It would be nice. However, I doubt if it is possible: the string within
> _() will be expanded by preprocessor and glued together by cc itself,
> which means it will result in different literal strings on different
> machines. Gettext will have no means of knowing how exactly is PRIuSIZE
> expanded, so it will not be able to match the msgid.

That is already solved for other PRIxyy-macros by Bruno Haible I think.
This (untested) patch adds support for PRI*SIZE-macros to gettext,
which of course should to be defined somewhere else as well...

Regards

Oskar
diff -u -p loadmsgcat.c.v0 loadmsgcat.c
--- loadmsgcat.c.v0	2005-05-20 22:07:47.000000000 +0200
+++ loadmsgcat.c	2005-10-01 10:47:52.000000000 +0200
 <at>  <at>  -450,6 +450,48  <at>  <at>  char *alloca ();
    sizeof (void *) == sizeof (int) ? "X" : \
    "llX")
 #endif
+#if !defined PRIdSIZE || PRI_MACROS_BROKEN
(Continue reading)

Simon Josefsson | 1 Oct 11:19 2005

Re: coreutils-5.90 build feedback

Jim Meyering <jim <at> meyering.net> writes:

>> On Compaq Alpha OSF/1 5.1:
>>
>> 	c89 -DHAVE_CONFIG_H -DLIBDIR=\"/uufs/inscc.utah.edu/common/home/mthnhb/alpha/local/lib\"
-I. -I. -I..
>> 	 -I.. -I. -I/uufs/inscc.utah.edu/common/home/mthnhb/alpha/local/include  -ieee
>> 	-I/uufs/inscc.utah.edu/common/home/mthnhb/alpha/local/include -c getaddrinfo.c
>> 	...
>> 	cc: Error: getaddrinfo.h, line 31: In this declaration, the struct "addrinfo" is redefined.
>> 	(redefstruct)
>> 	struct addrinfo
>> 	^
>> 	cc: Error: getaddrinfo.h, line 91: In this declaration, the type of "gai_strerror" is not compatible
>> 	with the type of a previous declaration of "gai_strerror" at line number 293 in file
>> 	/usr/include/netdb.h. (notcompat)
>> 	extern const char *gai_strerror (int ecode);
>>
>> I'm doing a new build with cc on that system.
>
> This is happening because getaddrinfo.h defines struct addrinfo
> and declares gai_strerror merely because the system lacks the
> getaddrinfo function.  But this system already has those in netdb.h,
> and they conflict.
>
> Simon, I think the guards should be more precise.
> I.e., use HAVE_GETADDRINFO only for the getaddrinfo declaration.
> Then test for gai_strerror and guard its declaration with HAVE_GAI_STRERROR.
> Similarly for struct addrinfo.
>
(Continue reading)

Jim Meyering | 1 Oct 11:57 2005
Picon

Re: coreutils-5.90 build feedback

Simon Josefsson <jas <at> extundo.com> wrote:
> Yes, I'll work on this.
>
> How about this patch?  Not exactly like you suggested, but appears
> good to me.  I have not tested this, but if it looks good for you,
> I'll install it in my projects and rebuild them, then we can sort out
> any remaining build problems later on.

Thanks.
I've checked that in to coreutils and will test it, too.

I've also just checked the following in to gnulib:

2005-10-01  Jim Meyering  <jim <at> meyering.net>

	Sync from coreutils.

	* getaddrinfo.m4 (gl_GETADDRINFO): Look for getservbyname in these
	libraries [inet nsl socket xnet].  Nelson Beebe reported that with
	native cc on Solaris 7, getaddrinfo.c requires -lsocket.
	* getaddrinfo.m4 (gl_GETADDRINFO): Check for gethostbyname
	in the inet and nsl libraries.  Required on Solaris 5.7.

Gmane