Re: [hackers] [dwm][PATCH RESEND 0/2] Const-correctness fixes

From: Chris Down <chris_AT_chrisdown.name>
Date: Mon, 22 Aug 2022 12:24:33 +0100

Quentin Rameau writes:
>> Hi Quentin,
>
>Hey Cris,
>
>> In general the existing code seems confused, no?
>
>A code isn't confused, the reader might be though.

I beg to differ when the code declares something const but later then decides
it isn't ;-)

>Is there something you are not actually understanding here?

No, but the code seems unnecessarily obtuse.

>> Either we shouldn't pass them in as const in the first place,
>> or we should maintain the constness that we
>> declare in the function parameters.
>
>The constness is “maintained” here, the function gets a "const FcChar8 *"

That's quite different: the code passes it a FcChar8* which it then treats as a
const FcChar8*. Case in point, GCC 12.1.1 and clang 14.0.6 both generate
different code.

I really don't see why we would break the chain of const custody intentionally,
it seems a super weird thing to push back against.

>> There shouldn't be any logical change here, but it seems weird to say things
>> are not mutable up front and then waver about it later. Right now there's no
>> UB, but making sure we don't cast away the const mitigates the risk altogether.
>
>There is no risk here.

Likely, but we're relying on system libs with unknown ABI version. Making it
`const` makes our intentions clear and avoids confusedly turning a const
variable into a non-const one. This isn't a bug fix.

>I think that the cast here is actually unnecessary, isn't it?

No, because FcChar8 is unsigned, but the default signedness of char may be
either way.
Received on Mon Aug 22 2022 - 13:24:33 CEST