Здравствуйте, c-smile, Вы писали:

К>>А можно в двух словах, каким образом знаковость влияет на работу PCRE?

CS>Да вот тебе пример из жизни:

Я понимаю, как можно самому накосячить со знаковостью. Интересно другое: есть ли такие косяки именно в PCRE?
Не обязательно детские, типа того, который ты привёл. А, например, такое
"/[\x70-\x90]/" — поддержка диапазонов, пересекающих черту ASCII

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, c-smile, Вы писали:

CS>>Здравствуйте, Кодт, Вы писали:

К>>>А можно в двух словах, каким образом знаковость влияет на работу PCRE?

CS>>Да вот тебе пример из жизни:

CS>> return u8text[0] == 0xEF &&
CS>> u8text[1] == 0xBB &&
CS>> u8text[2] == 0xBF;

N>И что? Вижу пример, как знаковость влияет на плохо написанный код. Но не вижу, как она влияет на работу PCRE. Следует помнить, что это библиотека с длинной историей, богатой функциональностью и огромным накопленным опытом мультиплатформенного применения, и уж такими мелочами, как signed char, её не сломать.

Я собственно не про PCRE а про то что unsigned char как тип эта та соломка которую подстилают при работе с utf-8.
Чтобы не было таких косяков на пустом месте.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, c-smile, Вы писали:

К>>>А можно в двух словах, каким образом знаковость влияет на работу PCRE?

CS>>Да вот тебе пример из жизни:

К>Я понимаю, как можно самому накосячить со знаковостью. Интересно другое: есть ли такие косяки именно в PCRE?
К>Не обязательно детские, типа того, который ты привёл. А, например, такое

Там блин вест файл был написан не по детски т.е. все нормально было со знаковостью ибо был изначальный каст на unsigned char*
но вот одно такое место (как я привел) привело к не детским последствиям.

К>"/[\x70-\x90]/" — поддержка диапазонов, пересекающих черту ASCII

Это вот как раз очевидный test case. Гораздо интереснее будет скажеи вот такое "/[\x70-\xC3]/"

Здравствуйте, c-smile, Вы писали:

К>>Я понимаю, как можно самому накосячить со знаковостью. Интересно другое: есть ли такие косяки именно в PCRE?
К>>Не обязательно детские, типа того, который ты привёл. А, например, такое

CS>Там блин вест файл был написан не по детски т.е. все нормально было со знаковостью ибо был изначальный каст на unsigned char*
CS>но вот одно такое место (как я привел) привело к не детским последствиям.

В смысле, ты процитировал исходники PCRE?! Тогда — вау!

К>>"/[\x70-\x90]/" — поддержка диапазонов, пересекающих черту ASCII

CS>Это вот как раз очевидный test case. Гораздо интереснее будет скажеи вот такое "/[\x70-\xC3]/"

А здесь что за заподло? Имеется в виду, что 0xC3 — это голова мультибайта, или что?

Здравствуйте, Кодт, Вы писали:

К>>>"/[\x70-\x90]/" — поддержка диапазонов, пересекающих черту ASCII

CS>>Это вот как раз очевидный test case. Гораздо интереснее будет скажеи вот такое "/[\x70-\xC3]/"

К>А здесь что за заподло? Имеется в виду, что 0xC3 — это голова мультибайта, или что?

А вот что оно такое в свете PCRE и utf-8 support. Т.е. там не только проверка диапазона start < end но еще и коллизии с запрещенными utf-8 комбинациями. Вообще PCRE внутри должен оперировать uchar_t который есть uint21.

Здравствуйте, c-smile, Вы писали:

N>>И что? Вижу пример, как знаковость влияет на плохо написанный код. Но не вижу, как она влияет на работу PCRE. Следует помнить, что это библиотека с длинной историей, богатой функциональностью и огромным накопленным опытом мультиплатформенного применения, и уж такими мелочами, как signed char, её не сломать.

CS>Я собственно не про PCRE а про то что unsigned char как тип эта та соломка которую подстилают при работе с utf-8.
CS>Чтобы не было таких косяков на пустом месте.

Ну это и так понятно. Но я бы акценты сместил: я вообще не понимаю, какого аккредитива и зачем был введён и используется signed char, а тем более кто и зачем включает его по умолчанию. Это же постоянные грабли на ровном месте.