Re: support for ISO C 99 format string directive macros in gettext

[Bruno Haible <haible at ilog dot fr>]

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