kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 17/10/2018 à 14:01, jp charras a écrit :
> 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.
> 

Besides, I did not see issues with UTF8 chars larger than 16-bits on
Windows with the previous code (but I did not make a lot of tests).

-- 
Jean-Pierre CHARRAS