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

From: Quentin Rameau <quinq_AT_fifth.space>
Date: Mon, 22 Aug 2022 17:39:40 +0200

> I beg to differ when the code declares something const but later then decides
> >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 don't see why it would, and I can't reproduce it with a simple test-case.
Could you share a source/output somewhere of that?

> 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.

Hence my proposal to remove the cast entirely.

> >> 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.

The intention is to pass a fontname to FcNameParse.
Indeed, the cast makes that a bit unclear apparently,
leading to this discussion.

> >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.

And? FcNameParse will use whatever is passed
as a pointer to an unsigned char.
Received on Mon Aug 22 2022 - 17:39:40 CEST