tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [RFC] introducing new locale-db implementation (Re: lib/39662: shortcomings in LC_{MONETARY,NUMERIC,TIME,MESSAGES} db format)

On Fri, Jan 02, 2009 at 02:41:37AM +0900, Takehiko NOZAKI wrote:
> happy new year! all.
> let's remember following discussion about locale-db format.
> let me summarize:
> 1. the lack of magic number, no versioning mechanism is the killer
>    for backward binary compatibility for libc itself.
> 2. plain-text based db file can't afford to store wide string data,
>   it is not good idea "on the fly" conversion, we need more efficient format
>   that can easily handle byteorder(3) issue.
> 3. making /usr/share/locale/*/LC_MESSAGES as the monolithic file
>    give us the confliction with gettext(3)'s namespace,
> 4. we're already have too many locale db format,
>   LC_CTYPE(rune), *.cat(catgets), *.mo(gettext), citrus_db(iconv)
>   introducing another format is not good idea.
> before the shipping of 5.0, we have to fix these problems (this
> problem is already filed as PR/39662, and blocker for netbsd-5).
> so i wrote brand new localedata implementation for LC_*.
> it uses citrus_db framework as backend(we're already uses citrus_db
> to implement iconv).
> here is the patch to HEAD and netbsd-5.
> i've already checked this patch doesn't break release build:
>    i386, amd64, hpcarm, hpcmips, hpcsh, vax.
> i want to commit this patch into HEAD and send pullup-5 request.
> is there any objection, or comments?

On behalf of 5.0 release engineering team, and also the core team,
we'd like to thank you very much for all your work, and would like to
ask you to please commit the patch into HEAD.

With thanks,

Home | Main Index | Thread Index | Old Index