On Fri, Sep 27, 2019 at 4:41 PM Lewis Hyatt <lhy...@gmail.com> wrote: > > On Thu, Sep 26, 2019 at 08:46:56PM +0000, Joseph Myers wrote: > > On Thu, 26 Sep 2019, Lewis Hyatt wrote: > > > > > A couple notes: > > > - In order to avoid any portability problems with wchar_t, the > > > equivalent of wcwidth() from libc is implemented in-house. > > > > I'm uneasy about contrib/gen_wcwidth.cpp doing the generation using host > > libc's wcwidth. The effect is that libcpp/generated_cpp_wcwidth.h is > > *not* reproducible unless you know exactly what host (libc version, locale > > used when running the program, distribution patches to libc and locale > > data) was used to run the program. I think we need a generator that works > > from Unicode data in some way so we can explicitly say what version of the > > (unmodified) Unicode data was used. > > Here is a revised patch that hopefully addresses your concerns. I borrowed the > relevant Python code for parsing Unicode's data files from glibc, then added a > new script that parses the locale data they output into the same sort of > simply > searchable tables I was creating before. The new generated table is very close > to the old one, but there are some differences due to improvements that have > been made to glibc recently, affecting 200 or so codepoints.
This patch (https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01627.html) now requires some minor merge resolution, after recent other commits affecting diagnostic-show-locus.c. I wasn't sure what's the preferred practice, should I resend it now so that you have something that can be applied to trunk, or it's better to wait for comments on what was already sent? Thank you! -Lewis
