[FFmpeg-devel] [PATCH] avfilter: add wpsnr video filter

[Andreas Rheinhardt]

Ronald S. Bultje:
> Hi Thomas,
> 
> On Fri, Oct 29, 2021 at 9:12 AM Tomas Härdin <tjoppen at acc.umu.se> wrote:
> 
>> tor 2021-10-28 klockan 21:09 +0200 skrev Paul B Mahol:
>>> +    const uint16_t *src = (const uint16_t *)ssrc;
>>
>> This is not -fstrict-aliasing safe
>>
> 
> I don't believe that is correct. It's true we're not allowed to cast
> between two clashing types to access the same pointer (memory location),
> but the C standard would appear to make an exception for byte types.
> 
> Quoted from https://stackoverflow.com/a/99010/4726410 because I'm too lazy
> to dig through the standard:
> 
> "The types that C 2011 6.5 7 allows an lvalue to access are:
> - a type compatible with the effective type of the object,
> - a qualified version of a type compatible with the effective type of the
> object,
> - a type that is the signed or unsigned type corresponding to the effective
> type of the object,
> - a type that is the signed or unsigned type corresponding to a qualified
> version of the effective type of the object,
> - an aggregate or union type that includes one of the aforementioned types
> among its members (including, recursively, a member of a subaggregate or
> contained union), or
> - a character type."
> 
> uint8_t is a variant of the character (aka byte) type, and so the cast
> would not seem to violate strict aliasing rules.
> 

1. uint8_t is not guaranteed to be a character type.
2. You are completely misreading this: The character type exception
means it is legal to access (read and write) anything through a
character type; it does not say that you may use anything to access
characters.
3. Yet this does not mean that what is being done here is UB: It depends
on the effective type of ssrc. Just because ssrc is of type const
uint8_t* does not make the effective type of the object it points to
const uint8_t. If the user has written to this object via an lvalue of
type uint16_t or copied data (via e.g. memcpy) from an object with
effective type uint16_t, then this is completely legal wrt. the
strict-aliasing rule. In practical terms this means that the compiler
may only presume that this is UB if it can prove that the effective type
of the object it points to is different from uint16_t. It may not just
infer this from the cast alone.
4. Notice that the cast would be UB if the pointer is not suitable
aligned for an uint16_t*. (This is different from the strict-aliasing
rule, yet violations of the latter may easily lead to alignment violations.)

- Andreas