[FFmpeg-devel] [PATCH] avcodec: add farbfeld encoder

[Andreas Rheinhardt]

Rémi Denis-Courmont:
> 
> 
> Le 4 juin 2024 00:56:21 GMT+03:00, Andreas Rheinhardt <andreas.rheinhardt at outlook.com> a écrit :
>> Rémi Denis-Courmont:
>>> Le maanantaina 3. kesäkuuta 2024, 22.29.13 EEST marcus a écrit :
>>>>> Bogus cast / aliasing violation.
>>>>
>>>> I thought qualifiers don't affect aliasing rules in C. Am I wrong?
>>>
>>> If they didn't, the compiler wouldn't warn about incompatible pointer type 
>>> conversions in the absence of the explict cast.
>>>
>>
>> Wrong: The conversion uint8_t*const*->const uint8_t * const* is safe
> 
> Nope. The pointer types have the same representation and in practice neither LLVM IR nor GIMPLE can differentiate them, but they are not compatible according to spec (C11 §6.7.6.1).
> 
> You can convert `const uint8_t **` to `const uint8_t *const *`, for sure (C11 §6.3.2.3), but that's not the same conversion

"Similarly, pointers to qualified or unqualified versions of compatible
types shall have the same representation and alignment requirements."
(C11 6.2.5 28) This implies that the cast uint8_t*const*->const uint8_t
* const* obeys the alignment requirement from 6.3.2.3 7.
(It does not imply that the cast is a no-op; these two types may have
different object representations, although I don't think that this has
ever happened for any practical implementation.)

When av_image_copy_to_buffer() dereferences this pointer, it will read
from the array of pointers via an lvalue expression of type const
uint8_t* and this is legal because the effective type is uint8_t* and
reading via a qualified type is fine ("An object shall have its stored
value accessed only by an lvalue expression that has one of the
following types: [...] a qualified version of a type compatible with the
effective type of the object" 6.5 7) Given that const uint8_t* and
uint8_t* have the same size, the same is true when accessing via
pointer+offset.

- Andreas