Re: [PATCH 1/3] test-ctype: test isascii

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2023, 03:39 UTC
Message-ID: <xmqqttzqcjyj.fsf@gitster.g>
In-Reply-To: <70f4042a-df30-26e5-55bd-b349cc02c416@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 20 quoted lines

> Am 11.02.23 um 20:48 schrieb Junio C Hamano:
>> René Scharfe <l.s.r@web.de> writes:
>>
>>> Test the character classifier added by c2e9364a06 (cleanup: add
>>> isascii(), 2009-03-07).  It returns 1 for NUL as well, which requires
>>> special treatment, as our string-based tester can't find it with
>>> strcmp(3).  Allow NUL to be given as the first character in a class
>>> specification string.  This has the downside of no longer supporting
>>> the empty string, but that's OK since we are not interested in testing
>>> character classes with no members.
>>
>> I wonder how effective a test we can have by checking a table we use
>> in production (i.e. ctype.c::sane_ctype[]) against another table we
>> use only for testing (i.e. string literals in test-ctype.c), but
>> that is not something new in this series.
>
> What aspect is left uncovered?
>
> Or do you mean that the production table should be made trivially
> readable to avoid having to test at all?

Much closer to the latter but not quite.

Both tables are not all that transparent, and it feels that the protection by the tests largely depends on the fact that it is less likely for us to make the same mistake in two "not so crystal clear" tables for the same byte.

> ... but parsing commit messages and blob
> payloads should perhaps better be done with locale-aware versions
> with multi-byte character support.

Yes, that does make sense but it is orthogonal to what sane_ctype wants to address, I would think.