Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>> > -BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
>> > BASIC_CFLAGS += -fno-omit-frame-pointer
>> > +BASIC_CFLAGS += -fsanitize=$(SANITIZE) -fno-sanitize-recover=$(SANITIZE)
>> > ifneq ($(filter undefined,$(SANITIZERS)),)
>> > BASIC_CFLAGS += -DSHA1DC_FORCE_ALIGNED_ACCESS
>> > endif
>> > -- snap --
>>
>> I opted to exclude this hunk because it didn't seem like a list that
>> should be sorted. Perhaps if we include this in the static-analysis
>> script, we could define a whitelist of lists that we want to keep
>> sorted?
>
> I agree, modulo s/whitelist/allow list/.
If we were to do this, I agree that explicitly enumerating "lists
whose elements must be sorted" would be a much better approach than
declaring that our lists by default must be sorted and have a list
of "lists whose elements are sorted in an order that has meaning,
not just by codepoints".
But I somehow find the use of allow-list (as a concept [*1*])
awkward in this context. Technically, a list of things whose
sortedness we care about may be "allowed to be automatically
modified", and the remainder would be "forbidden from getting
touched". But both are quite awkward way to think about them.
It would become even more awkward if the list is going to be used in
a make target whose name has "check" in it, in which case the target
would only point out problem so that the user can fix, and at that
point, the said list would become a list of things that are "allowed
to be checked".
[Footnote]
*1* ... not the phrase---I do not care in what color the allowed
things are painted.
