Date: Mon, 10 Sep 2018 12:39:59 +1200 From: Thomas Munro <munro@ip9.org> To: yuripv <yuripv@yuripv.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Tracking CLDR version in collation definitions Message-ID: <CADLWmXX1SiOSf%2BsiB-94UnDdhVpCrZMh9DbaYfMPcuZ=sP9_OQ@mail.gmail.com> In-Reply-To: <1536416542111-0.post@n6.nabble.com> References: <CADLWmXWY0doSQ-7uoBC0JUzCgZTx9iw-k_viYWB7ze8Pi7R8gw@mail.gmail.com> <1536416542111-0.post@n6.nabble.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 September 2018 at 02:22, yuripv <yuripv@yuripv.net> wrote: > Hi Thomas, > > I think this makes perfect sense, yes, and not aware of any other way of > having the data version information. Thanks for the feedback. This is reassuring. Yeah I've looked around a bit. > There are some nits in the man page changes, but that can of course be taken > care of during review. Cool -- I will do some more work on this and post a differential. > A bigger question is backwards compatibility as you seem to be changing the > on-disk format -- I can't think of anything bad happening off the top of my > head, just wondering if you had some ideas on it. The on-disk format I propose is deliberately forwards AND backwards compatible. That region of the file is currently full of zeroes. If you call the new function for an older LC_COLLATE file, you just get an empty string. If you access a file that does have the new version using an older libc, it ignores that region of the file.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLWmXX1SiOSf%2BsiB-94UnDdhVpCrZMh9DbaYfMPcuZ=sP9_OQ>