This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: support for ISO C 99 format string directive macros in gettext
Paul Eggert writes:
> * Since the system-dependent translations can be guaranteed to be
> shorter than the system-independent translations, can't loadmsgcat.c
> modify the latter strings in place? That way, it wouldn't need to
> malloc the translated strings; it would need only to mmap them
> differently.
But the copy-on-write semantics that you get with MAP_PRIVATE and
PROT_READ|PROT_WRITE is to copy an entire 4 KB page of memory. For
small .mo files which typically contain no more than 3
system-dependent strings it's a waste of memory. (Note that you have
to have a writable copy of the hash table in either case - it doesn't
make a difference whether the PROT_WRITE or the malloc approach is
taken.)
Furthermore, I wouldn't bet on strlen (PRIdMAX) <= 7. The current
support might some day also be used for other kinds of string
expansions like "~" -> "/home/user".
> * As a user, I'd rather have portable support for concise ISO C99
> formats like %jd than for their verbose equivalents like %"PRIdMAX".
> For example, I'd rather write this:
>
> printf (_("total = %jd bytes"), total);
>
> than this:
>
> printf (_("total = %" PRIdMAX " bytes"), total);
>
> Can this be arranged? It'd be nice.
Yes it would be nice. But that's not how the standards (ISO C 99 +
POSIX 2001) specify it.
> * You can combine the above two ideas to avoid the need for any
> malloc, even for hash tables. Instead of PRIdMAX, you tell the user
> to use (say) gtPRIMAX, e.g.:
>
> printf (_("total = %" gtPRIMAX "d bytes"), total);
>
> gtPRIMAX can expand to a string of gettext's design, which is the
> same on all platforms.
This doesn't work, because when NLS is disabled, _ expands to noop,
and you would pass this format directive of gettext's design to the
platform's printf function.
Bruno