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. Ciao, Johannes _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
