[PATCH] Silence misguided GCC warning about alignment issues

[Johannes Schindelin]

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.schindelin at 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