mirror of https://git.musl-libc.org/git/musl
Tree:
1b0ce9af6d
master
rs-1.0
v0.5.0
v0.5.9
v0.6.0
v0.7.0
v0.7.1
v0.7.10
v0.7.11
v0.7.12
v0.7.5
v0.7.6
v0.7.7
v0.7.8
v0.7.9
v0.8.0
v0.8.1
v0.8.10
v0.8.2
v0.8.3
v0.8.4
v0.8.5
v0.8.6
v0.8.7
v0.8.8
v0.8.9
v0.9.0
v0.9.1
v0.9.10
v0.9.11
v0.9.12
v0.9.13
v0.9.14
v0.9.15
v0.9.2
v0.9.3
v0.9.4
v0.9.5
v0.9.6
v0.9.7
v0.9.8
v0.9.9
v1.0.0
v1.0.1
v1.0.2
v1.0.3
v1.0.4
v1.0.5
v1.1.0
v1.1.1
v1.1.10
v1.1.11
v1.1.12
v1.1.13
v1.1.14
v1.1.15
v1.1.16
v1.1.17
v1.1.18
v1.1.19
v1.1.2
v1.1.20
v1.1.21
v1.1.22
v1.1.23
v1.1.24
v1.1.3
v1.1.4
v1.1.5
v1.1.6
v1.1.7
v1.1.8
v1.1.9
v1.2.0
v1.2.1
v1.2.2
v1.2.3
v1.2.4
v1.2.5
v1.2.6
${ noResults }
1 Commits (1b0ce9af6d2aa7b92edaf3e9c631cb635bae22bd)
| Author | SHA1 | Message | Date |
|---|---|---|---|
|
|
1b0ce9af6d |
new wcwidth implementation (fast table-based)
i tried to go with improving the old binary-search-based algorithm, but between growth in the number of ranges, bad performance, and lack of confidence in the binary search code's stability under changes in the table, i decided it was worth the extra 1.8k to have something clean and maintainable. also note that, like the alpha and punct tables, there's definitely room to optimize the nonspacing/wide tables by overlapping subtables. this is not a high priority, but i've begun looking into how to do it, and i suspect the table sizes can be roughly halved. if that turns out to be true, the new, fast, table-based implementation will be roughly the same size as if i had just extended the old binary search one. |
14 years ago |