Ronald S. Bultje: > Hi Thomas, > > On Fri, Oct 29, 2021 at 9:12 AM Tomas Härdin <tjop...@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 _______________________________________________ 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".