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
- From: Paul Eggert <eggert at twinsun dot com>
- To: haible at ilog dot fr
- Cc: libc-alpha at sources dot redhat dot com
- Date: Tue, 23 Jul 2002 00:32:19 -0700 (PDT)
- Subject: Re: support for ISO C 99 format string directive macros in gettext
- References: <15676.372.480110.140779@honolulu.ilog.fr>
Thanks for writing that; it attacks a sore spot. Here are a few ideas
for more improvement:
* 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.
* 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 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. 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@".
Then loadmsgcat.c don't need a separate system-dependent-string
section. Insted, it merely needs to rewrite the translated
format-strings in-place before using them. This can be done by
scanning the format strings and looking for formats like "%...j..."
and "%...@PRIFAST32@..." that need to be rewritten.
A disadvantage of this last approach is that it can't support strings
that are partly format strings and partly non-format strings (e.g.,
"%/%!foo%@" PRIdMAX "bar"). But I don't think this is something
gettext needs to support.