Le 17/10/2018 à 13:45, jp charras a écrit : > Le 17/10/2018 à 01:51, Seth Hillbrand a écrit : >> Hi All- >> >> Our UTF-8 routines are mildly fragile and didn't play nicely with >> higher-order unicode sequences [1] causing a segfault for anything >> larger than 16-bits. >> >> I've pushed a fix that changes how wchar_t* characters are assigned to >> the UTF8 class. This is a band-aid fix as it doesn't address the >> underlying problems with utilizing wchar (this is compiler dependent) >> but it keeps us from crashing and I don't think that our stroke font >> goes into the higher levels. >> >> That said, because this is compiler dependent, it would be very helpful >> to get some additional testing under Windows in particular. Please see >> if you can correctly name nets with a few glyphs from [2]. Ones that >> are not in our stroke table should display with '?' but remain correctly >> displayed in the textbox when you edit the label again. Ones in the >> stroke table should display correctly in both. >> >> Thanks! >> Seth >> >> [1] https://bugs.launchpad.net/kicad/+bug/1798144 >> [2] https://en.wikipedia.org/wiki/List_of_Unicode_characters > > Hi Seth, > > With this fix, on W7 32 bits, msys2, Eeschema crashes at start, when run > from Kicad manager. > Strangely, it runs when started as stand alone. > > Gdb is not useful to know what happens. > >
More test: In fact eeschema crashes when reading the .sch file that contains the UFT8 char. I used in my test the char 'ñ' (OxC3 OxB1 utf8 code) in a label. This is the reason it crashed when starting from Kicad. Note, without the fix, the .sch file is loaded without issue. -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
