tech-userlevel archive

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

Re: localeio



[source-changes trimmed from Cc]

On Wed, May 21, 2008 at 02:00:46PM +0900, SODA Noriyuki wrote:
> [Sorry, this is a repost, since I made same mistake in the Cc: header ;)]
> 
> >>>>> On Wed, 21 May 2008 03:51:47 +0000,
>       Brian Ginsbach <ginsbach%netbsd.org@localhost> said:
> 
> >> The following change has some serious problems.
> >> 
> >> e.g.
> >> - The database format doesn't have a magic number.
> >> So, there is no chance to change the format.
> 
> > I know but the EXISTING LC_TIME stuff didn't either.  This was just
> > a generalization of the existing logic.  The LC_TIME stuff has been
> > there with exactly the same format for over a year.  Originally
> > committed by Emmanuel Dreyfus (manu).
> 
> Yeah, that's a part of problem.  And spreading the problem is not a
> good thing.
> And

Were there objections to the original code?

> 
> > Also note that FreeBSD has used this same "database" format for
> > something like seven years.
> 
> FreeBSD's locale database has more problems.  That's why we didn't
> just import it.

Please point out what you think the problems are with FreeBSD's
format.

If the FreeBSD "database" format has such problems they why haven't
they fixed them in seven years?

> 
> > The current format is basically a flat text file.  If a more binary
> > format is required/desired, it should be possible design a header,
> > with a magic number and version, that can easily be distinguished
> > from the current and a new format.
> 
> I think it's is better to introduce the magic at the first point.
> And that's possible in this case isn't it?

Maybe.  However changing to add magic would "break" the -current
LC_TIME implementation.  I'm still not convinced that the added
complexity is necessary.

> 
> >> - The design doesn't consider the copy directive of localedef(1).
> 
> > It is not supposed to.  It is only supposed to be the internal
> > format used by the library.  The copy directive of localedef(1) --
> > which I've been working on when I have time -- is not used in the
> > final form by the LIBRARY.  It is a directive that tells localedef(1)
> > to copy the information from one locale when creating another.  I
> > think you are confusing things.  
> 
> So, you expect creating a copy of the original, instead a referecne to
> the orignal. OK.

This is how all implementations that I've looked at work.  The
directive is never carried through to the output.  The directive
is for localedef(1).  I wouldn't expect to see it in the output
that is used in the library.

> 
> >> Since these will introduce compatibility problem, I believe it is
> >> better to disable this implementation temporarily for now.
> >> 
> >> I think review by Nozaki-san (tnozaki@netbsd) is necessary
> >> as well as by christos.
> 
> > It was reviewed and OK'ed by christos.  He did not feel, at the
> > time, it needed a wider audience.
> 
> Yeah, I know, and I'm not blaming you, of course.
> I'm just suggesting.

Understood.  It is getting a wider audience now.  I've not heard
other comments.


Home | Main Index | Thread Index | Old Index