This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> From: Bruno Haible <haible@ilog.fr>
> Date: Tue, 23 Jul 2002 14:09:01 +0200 (CEST)

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

For small files it doesn't matter so much, since they use little
memory either way.  (Even for small files, it's not clear to me that
using malloc will use fewer pages; I suppose it depends on malloc.)

I'd like to avoid malloc in gettext, because I don't want error
messages to come out in English when programs are reporting malloc
failures.  However, I guess that if the mallocs are all done when then
message libraries are loaded, and are never done after that, then it's
OK, as apps already have the problem of outputting English when the
message libraries can't be loaded.


> (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.)

Can't we make the hash table read-only by omitting the
system-dependent part of the strings from the input to hashing
function?  If we omit only the potentially-system-dependent printf
formats, this shouldn't hurt the quality of the hash much.

> Furthermore, I wouldn't bet on strlen (PRIdMAX) <= 7.

OK.  Another possibility would be to use mmap on systems like glibc
(and the vast majority of other systems) where strlen (PRI...) <= 3,
and to fall back on malloc on weird systems with longer
PRI... strings.  The decision about whether to use mmap or malloc
could be done at compile-time, since we know strlen (PRI...) by then.

Admittedly this would complicate the code, but I think it might
improve performance on GNU systems by putting less stress on malloc.
It's just a performance tuneup, though, so obviously it can wait.

> The current support might some day also be used for other kinds of
> string expansions like "~" -> "/home/user".

I didn't know about these string expansions that you are thinking of.
I hope that these expansions can all be done at message-catalog-load
time, for the reasons mentioned above.  I worry about the "~" ->
"/home/user" example, though: what happens if the program does putenv
("HOME=/some/other/path") after the message catalog gets loaded?


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

Sorry, I don't understand this comment.  In ISO C 99, "...%jd..." is
equivalent to "...%" PRIdMAX "..." as a printf format, so I don't see
why this idea is incompatible with ISO C 99.


> >      printf (_("total = %" gtPRIMAX "d bytes"), total);
> 
> 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.

Under this proposal, _ would not be a noop when NLS is disabled.
But admittedly this is getting a bit tricky.

I do have one other question.  What will xgettext etc. do when
message-IDs collide after replacement of system-dependent strings?
For example, suppose the program does this:

	printf (_("total = %" PRIdMAX " bytes"), total_max);
	printf (_("total = %" PRId64  " bytes"), total_64);

Presumably there will be two msgids to translate here, since PRIdMAX
might differ from PRId64?  But at runtime the msgids might be
identical, so which of the two translations will be chosen by gettext?
Will xgettext warn about potential collisions like this?

Anyway, thanks for listening to my ideas and questions.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]