[haiku-commits] Re: r34154 - haiku/trunk/src/bin/coreutils/src
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 28 Nov 2009 15:38:17 +0100
Jérôme Duval <korli@xxxxxxxxxxxxxxxx> wrote:
> 2009/11/22 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> > Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> >> > * This is a temporary work-around to let "ls" show UTF-8
> >> > characters, even
> >> > though it won't determine the correct display width.
> >> > * The actual fix would be to have the wide character API
> > > > working,
> >> > though.
> >> Hm, which API do you mean? Anything missing in our wc... functions
> > > or
> >> are you talking about something different?
> > No, it's just that MB_CUR_MAX is defined to 1, and that disables
> > the
> > use of the wc* functions in bash - I thought that would mean that
> > they
> > don't work yet.
> Would it be OK to set MB_CUR_MAX to 4 in headers/posix/stdlib.h ?
> Also gcc's limits.h defines MB_LEN_MAX to 1, although its value would
> be 16. Could we override this in our own limits.h ?
> I tested locally with these changes and bash now behaves correctly
> regarding the backspace bug described by Stefano.
I think the MB_CUR_MAX macro should actually resolve to a function that
takes the current encoding into account. Of course, it should default
to UTF-8 for us (4 bytes), though.
Where does our wide character implementation get its (default) encoding
from?
Bye,
Axel.
Other related posts:
