Date: Tue, 23 Jan 2018 08:10:32 -0600 From: Kyle Evans <kevans@freebsd.org> To: Yuri Pankov <yuripv@icloud.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: libc/regex: r302824 added invalid check breaking collating ranges Message-ID: <CACNAnaF2aJ5EqLSCLTRkGH%2Bq5SYMmxD1dygGd8NFrkA9STJX8A@mail.gmail.com> In-Reply-To: <e192f9f7-9d9c-d1e3-8db4-02226ffa23d3@icloud.com> References: <a0d9abd8-19b8-cdf6-5451-e184fa182b38@icloud.com> <e192f9f7-9d9c-d1e3-8db4-02226ffa23d3@icloud.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 22, 2018 at 11:36 PM, Yuri Pankov <yuripv@icloud.com> wrote:
> On Tue, Jan 23, 2018 at 03:53:19AM +0300, Yuri Pankov wrote:
>>
>> (CCing Kyle as he's working on regex at the moment and not because he
>> broke something)
>>
>> Hi,
>>
>> r302284 added an invalid check which breaks collating ranges:
>>
>> -if (table->__collate_load_error) {
>> - (void)REQUIRE((uch)start <= (uch)finish, REG_ERANGE);
>> +if (table->__collate_load_error || MB_CUR_MAX > 1) {
>> + (void)REQUIRE(start <= finish, REG_ERANGE);
>>
>> The "MB_CUR_MAX > 1" is wrong, we should be doing proper comparison
>> according to current locale's collation and not simply comparing the
>> wchar_t values.
>
>
> After re-reading the specification I now see that what looked like a bug is
> actually an implementation choice, though the one that needs to be
> documentated. I'll update the man page if anyone is willing to review (and
> commit) the changes.
Can you point to the section of specification that indicates this is
OK behavior? It doesn't seem desirable, but I see that GNU systems
will operate in the same manner that we do now.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaF2aJ5EqLSCLTRkGH%2Bq5SYMmxD1dygGd8NFrkA9STJX8A>