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

[Ulrich Drepper <drepper at redhat dot com>]

On Tue, 2002-07-23 at 00:32, Paul Eggert wrote:

> * 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.

No, the mmap would remain as it is.  But before you start modifying the
mapped area you have to call mprotect.  And only on the region with is
affected.  This might be beneficial especially if the data is placed in
the file to affect as few pages as possible (add padding if necessary
when generating the code in msgfmt).


> * 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.  I suppose that on older hosts
>   that do not support %jd, gettext would have to translate the %jd
>   even in the C locale, but that's OK with me.

You try to solve two problems.  I personally could not care less about
systems which have inadequate support in the C library.  The printf
implementation on those systems should be used at all.  And this is
nothing needed or wanted in the libc code.

As for supporting %j etc.  I never understood why they've added it if
they have PRI.MAX.  Recognizing this would be possible but why? 
Document that whenever gettext is used the PRI* format has to be used
and be done with it.  Supporting %j just leads to problems.  E.g., your
fine "replace in place" mechanism wouldn't be possible.



>      printf (_("total = %" gtPRIMAX "d bytes"), total);
> 
>   gtPRIMAX can expand to a string of gettext's design, which is the
>   same on all platforms.  gtPRIMAX would obviously be "j", and so
>   nobody would need to use gtPRIMAX.  But gtPRIFAST32 would have to be
>   something special that can't collide with system formats,
>   e.g. "@PRIFAST32@".

Why should this be beneficial?  This would require work for every call
of gettext since the strings always have to be processed.  The method
Bruno has implemented does not require anything like this.  It simply
rewrites the strings and adds them to the normal hash table.  From that
point on the normal code is used.  An one-time up-front cost is much
preferrable to continuous cost throughout runtime especially since the
memory handling is much simpler this way (again: for %jd request makes
the replace inline optimization impossible).

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Attachment: signature.asc
Description: This is a digitally signed message part