Re: [PATCH v2 4/4] t-ctype: avoid duplicating class names

From: René Scharfe <l.s.r@web.de>
Date: Mar 6, 2024, 18:16 UTC
Message-ID: <3ef0927f-4d7b-4061-925e-c113d1c8730d@web.de>
In-Reply-To: <0947cb09-8b07-4fcd-bbe2-ae37c2cd5ec7@gmail.com>

Hello Phillip,

Am 04.03.24 um 10:51 schrieb Phillip Wood:

Show 16 quoted lines

> On 03/03/2024 10:13, René Scharfe wrote:
>> TEST_CTYPE_FUNC defines a function for testing a character classifier,
>> TEST_CHAR_CLASS calls it, causing the class name to be mentioned twice.
>>
>> Avoid the need to define a class-specific function by letting
>> TEST_CHAR_CLASS do all the work.  This is done by using the internal
>> functions test__run_begin() and test__run_end(), but they do exist to be
>> used in test macros after all.
>
> Those internal functions exist to implement the TEST() macro, they
> are not really intended for use outside that (which is why they are
> marked as private in the header file). If we ever want to update the
> implementation of TEST() it will be a lot harder if we're using the
> internal implementation directly in test files. Unit tests should be
> wrapping TEST() if it is appropriate but not the internal
> implementation directly.

forcing tests to be expressions and not allow them to use statements is an unusual requirement. I don't see how the added friction would make tests any better. It just requires more boilerplate code and annoying repetition. What kind of changes do you envision that would be hindered by allowing statements?

Show 7 quoted lines

> Ideally we wouldn't need TEST_CTYPE_FUNC as there would only be a
> single function that was passed a ctype predicate, an input array and
> an array of expected results. Unfortunately I don't think that is
> possible due the the way the ctype predicates are implemented. Having
> separate macros to define the test function and to run the test is
> annoying but I don't think it is really worth exposing the internal
> implementation just to avoid it.

The classifiers are currently implemented as macros. We could turn them into inline functions and would then be able to pass them to a test function. Improving testability is a good idea, but also somehow feels like the tail wagging the dog. It would be easy, though, I think. And less gross than:

>> Alternatively we could unroll the loop to provide a very long expression
>> that tests all 256 characters and EOF and hand that to TEST, but that
>> seems awkward and hard to read.

... which would yield unsightly test macros and huge test binaries. But it would certainly be possible, and keep the definitions of the actual tests clean.

René