Hi,
The "Intro" section of README.md contains a couple of incorrect statements:
-
"unlike the GNU implementation, it can even expand input strings containing so-called sysdep strings into a constant translation table."
GNU gettext does so too, since version 0.22 (June 2023).
-
"in the GNU implementation those are created at runtime"
Half correct. When processing a .mo file created by msgfmt versions older than 0.22, the sysdep strings are transformed at run time (see intl/loadmsgcat.c).
-
"which requires mapping the entire .mo file into read/write memory locations"
Not true. In the GNU implementation, the .mo file is mmap'ed with PROT_READ (see intl/loadmsgcat.c). Only the hash table (an array of uint32_t numbers) is copied into writable memory locations and augmented with values depending on sysdep strings (see variable inmem_hash_tab in intl/loadmsgcat.c).
Could you please correct the README.md? Thanks.
Hi,
The "Intro" section of README.md contains a couple of incorrect statements:
"unlike the GNU implementation, it can even expand input strings containing so-called sysdep strings into a constant translation table."
GNU gettext does so too, since version 0.22 (June 2023).
"in the GNU implementation those are created at runtime"
Half correct. When processing a .mo file created by msgfmt versions older than 0.22, the sysdep strings are transformed at run time (see intl/loadmsgcat.c).
"which requires mapping the entire .mo file into read/write memory locations"
Not true. In the GNU implementation, the .mo file is mmap'ed with PROT_READ (see intl/loadmsgcat.c). Only the hash table (an array of uint32_t numbers) is copied into writable memory locations and augmented with values depending on sysdep strings (see variable
inmem_hash_tabin intl/loadmsgcat.c).Could you please correct the README.md? Thanks.