bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some gcc warnings


From: Bruno Haible
Subject: Re: some gcc warnings
Date: Fri, 05 May 2017 00:24:18 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-75-generic; KDE/5.18.0; x86_64; ; )

Paul Eggert wrote on 2016-10-20:
> I'll leave rijndael-api-fst.c for Simon.

I'm still seeing the warnings with gcc-7.1:


rijndael-api-fst.c: In function 'rijndaelBlockEncrypt':
rijndael-api-fst.c:234:11: warning: dereferencing type-punned pointer will 
break strict-aliasing rules [-Wstrict-aliasing]
           ((uint32_t *) block)[0] = ((uint32_t *) input)[0] ^
           ^
rijndael-api-fst.c: In function 'rijndaelPadEncrypt':
rijndael-api-fst.c:317:11: warning: dereferencing type-punned pointer will 
break strict-aliasing rules [-Wstrict-aliasing]
           ((uint32_t *) block)[0] = ((uint32_t *) input)[0] ^
           ^
rijndael-api-fst.c: In function 'rijndaelBlockDecrypt':
rijndael-api-fst.c:390:11: warning: dereferencing type-punned pointer will 
break strict-aliasing rules [-Wstrict-aliasing]
           ((uint32_t *) block)[0] ^= ((uint32_t *) iv)[0];
           ^
rijndael-api-fst.c: In function 'rijndaelPadDecrypt':
rijndael-api-fst.c:484:11: warning: dereferencing type-punned pointer will 
break strict-aliasing rules [-Wstrict-aliasing]
           ((uint32_t *) block)[0] ^= ((uint32_t *) cipher->IV)[0];
           ^
rijndael-api-fst.c:484:11: warning: dereferencing type-punned pointer will 
break strict-aliasing rules [-Wstrict-aliasing]
rijndael-api-fst.c:495:7: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
       ((uint32_t *) block)[0] ^= ((uint32_t *) cipher->IV)[0];
       ^
rijndael-api-fst.c:495:7: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]


In gnupg's libgcrypt, Werner fixed it like this:
https://dev.gnupg.org/rCf17d50bbd31b1faa24af1e46c10bba845becf585
https://dev.gnupg.org/rCdfb4673da8ee52d95e0a62c9f49ca8599943f22e

But this fix is only effective for GCC. How could a compiler-independent fix
look like?

              Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]