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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |