Re: shadowing libc

[Bruno Haible <bruno clisp org>]

Behdad Esfahbod wrote:
> BTW, on Windows I'm sure people would write a backend to exchange
> locale data with the native database.  Maybe we should have a
> backend interface from the beginning.  Don't know what it means,
> but let's see, all of these have the same interface more or less:
>
>   - mmap()able file
>
>   - glibc mmap()able file
>
>   - glibc source file
>
>   - Windows backend (whatever the locale api provides, with
> registry used for the rest)

Very interesting point. Yes I agree that just like on Linux, some people
will want to use the glibc locale data, on Windows, some people will want
to use the native locale data as well. And code similar to
  gettext-runtime/glocale/cook/read-glibc.c
can also be written for the native Windows APIs.

At which point in time should the "data backend" be used? On Linux, for
speed, we use mmap()able files of our own. (Cannot use glibc's mmap()able
files since their format is undocumented and can change without notice.)
So the point of access to the data backend would need to be in the cooker.

Since I don't care about the speed of programs on Windows :-), I could agree
to putting the Windows backend in the runtime library rather than in the
cooker (i.e. make a Windows API call at every gl_nl_langinfo or gl_nl_strftime
call). But remember that when the user wants to apply local modifications to
the data or merge with CLDR data, the cooker will be used anyway.

Bruno