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