[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: performance bug of `wc -m`
From: |
Eric Fischer |
Subject: |
Re: performance bug of `wc -m` |
Date: |
Thu, 17 May 2018 19:02:32 -0700 |
On Thu, May 17, 2018 at 5:54 PM, Kaz Kylheku (Coreutils) <
address@hidden> wrote:
In what situation are there printable characters in the range [0,
> UCHAR_MAX) that
> have a width > 1?
I agree that it is unlikely, but POSIX doesn't specify anything about the
width of particular characters, so we don't have any guarantees. (There
could be a system that says that all printing characters are 20 units
wide.) We're not even guaranteed that the characters are in Unicode order.
So why make assumptions when you can ask the OS and be confident of being
portable?
Eric
- Re: performance bug of `wc -m` on glibc systems, (continued)
- Re: performance bug of `wc -m` on simulated macOS, Bruno Haible, 2018/05/20
- Re: performance bug of `wc -m` on macOS, Bruno Haible, 2018/05/20
- Re: performance bug of `wc -m` on macOS, Pádraig Brady, 2018/05/20
- Re: performance bug of `wc -m` on macOS, Bruno Haible, 2018/05/21
- Re: performance bug of `wc -m` on macOS, Bruno Haible, 2018/05/21
- speeding up `wc -m`, Bruno Haible, 2018/05/21
- Re: speeding up `wc -m`, Pádraig Brady, 2018/05/21
- Re: performance bug of `wc -m`, Kaz Kylheku (Coreutils), 2018/05/17
- Re: performance bug of `wc -m`,
Eric Fischer <=
Re: performance bug of `wc -m`, Kaz Kylheku (Coreutils), 2018/05/17
Re: performance bug of `wc -m`, Bruno Haible, 2018/05/20