Andreas Rheinhardt:
> Rémi Denis-Courmont:
>>
>>
>> Le 4 juin 2024 00:56:21 GMT+03:00, Andreas Rheinhardt
>> <andreas.rheinha...@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.
>
Wait, the second part is wrong: const uint8_t* and uint8_t* are not
qualified versions of a common type. So there is a effective type
problem, but ABI-wise it is fine by 6.2.5 28. I regard this as a defect
of the spec (just like the fact that the conversion uint8_t**->const
uint8_t*const* is not performed automatically) and not a real issue.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
