Hi, On Mon, 7 Aug 2017, Johannes Schindelin wrote:
> 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. Okay, nevermind, I misread the xz_crc32() function. The first parameter passed to crc32_block_endian0() is not the first parameter passed to xz_crc32(). And splitting the statement in two does indeed suggest that get_le32() is the actual cause for that warning. Ciao, Johannes _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox