On Mon, Aug 7, 2017 at 10:37 PM, Emmanuel Deloget <log...@free.fr> wrote: > > > > On Mon, Aug 7, 2017 at 9:46 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: >> >> Hi Denys, >> >> On Mon, 7 Aug 2017, Denys Vlasenko wrote: >> >> > On Mon, Aug 7, 2017 at 12:09 PM, Johannes Schindelin >> > <johannes.schinde...@gmx.de> wrote: >> > > When compiling xz_dec_stream.c with GCC 7.1.0, it complains thusly: >> > > >> > > In function 'dec_stream_footer': >> > > error: dereferencing type-punned pointer will break >> > > strict-aliasing >> > > rules [-Werror=strict-aliasing] >> > > if (xz_crc32(s->temp.buf + 4, 6, 0) != get_le32(s->temp.buf)) >> > > ^~ >> > > >> > > The thing is, the `buf` field was put just after two fields of type >> > > size_t for the express purpose of avoiding alignment issues, as per the >> > > comment above the `temp` struct. >> > > >> > > Meaning: GCC gets this all wrong and should not complain. So let's force >> > > it to be quiet for a couple of lines. >> > >> > xz_crc32 is: >> > >> > xz_crc32(const uint8_t *buf, size_t size, uint32_t crc) >> > >> > I think gcc is not complaining about xz_crc32, >> > it complains about get_le32! >> > >> > Can you test this theory by splitting that statement in two? >> >> I, too, thought at first that it is clearly about get_le32(), but GCC was >> really adamant that it was the xz_crc32() call. >> >> And a little further investigation suggests that GCC really meant >> xz_crc32(), which is defined as a static function in >> archival/libarchive/decompress_unxz.c that gets inlined by GCC because it >> simply hands off to crc32_block_endian0() which in turn takes an >> `uint32_t *` as first parameter. And that's where the type-punning is >> broken. >> > > This would be quite weird - the static function is by definition local to the > compilation unit, and the compiler cannot know about the content of > decompress_unxz.c from xz_dec_stream.c.
My bad. It's the other way round -- sorry for the noise. decompress_unxz.c includes xz_dec_stream.c (sometimes, the Busybox code is a bit hard to follow :)) And yes, its seems that the get_le32() macro in xz_private.h is a bit illegal with respect to strict aliasing, as it casts a uint8_t * into a const uint32_t *. > > BR, > > -- Emmanuel Deloget > _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
