Anthony J. Bentley wrote: > "Ted Unangst" writes: > > Fixing citrus is a pretty massive effort in itself. I'd prefer to see the > > replacement code prove itself as a separate API first, then we can remove > > citrus and change the wchar functions to use the new code. I'm less > > confident > > in a "meet in the middle" effort where we convert to wchar while > > simultanesou > > ly > > hoping the wchar code gets better. > > So how about a compromise? Use wchar_t where necessary, and no more > than that. After several programs get converted, come up with a better > wchar_t-free API, because at that time it becomes clear what kind of > functions are necessary.
Sure. I would rather see a dozen terrible diffs for different utilities than another dozen refinements to ls. I think we can safely say that we know putname() needs to be rewritten, but that tells us nothing about du. I don't think we will learn the best approach for the rest of bin just in ls, even if ls is a good test case. I think many of us would prefer to avoid wchar_t however, and while sprinkling it about may tell us what code we need to change, it doesn't help us discover the best API to use. That's why I was avoiding it. I have a simple test. I create /tmp/u then I populate it with a file called poop, then a file with two umlauts, then I use ksh to backspace over half of an umlaut. Then I run ls, ls | ul, du *, file *, etc. and observe all manner of damage. Two things are obvious. Programs use isprint()/strvis() without consideration of unicode. And programs use strlen() for widths. For this simple test case, even simplistic utf8 functions are sufficient to identify the code changes necessary. Stub functions don't need width tables for all of unicode, but enable us to see the API in action. Once the functions are in place, they can grow up. Anyway, I think we've spent too much time discussing. It wasn't all fruitless, but I think a dozen diffs to /usr/bin would have revealed what's needed, what works, and what doesn't with greater clarity. Shut up and hack! :)
