Re: BusyBox top buffered and the cached memory
Klaaßen, Fynn (LAWO) wrote: > I guess, there is a trivial bug when using busybox top: > > BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) multi-call binary: > > Mem: 3278296K used, 1236784K free, 0K shrd, 35373432K buff, 140001458828604 K > cached This has been fixed a while ago in | 7df1f1dda1f997c44800d16a9a12cf6cae2ed7e7 is the first bad commit | commit 7df1f1dda1f997c44800d16a9a12cf6cae2ed7e7 | Author: Timo Teräs | Date: Mon Jul 21 14:14:24 2014 +0300 | | top: fix and merge code to parse /proc/meminfo Unfortunately, the version of busybox shipped in Debian/Ubuntu is fairly outdated. This however is going to change soon-ish. For the time being, just a typo reported by Debian's obnoxious lint checker "lintian": I: busybox-static: spelling-error-in-binary bin/busybox compatiblity compatibility (That's in util-linux/fdisk.c) Cheers, Christoph ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash/hush: implement -d DELIM option for `read`
On Mon, Aug 7, 2017 at 6:18 PM, Johannes Schindelin wrote: > The POSIX standard only requires the `read` builtin to handle `-r`: > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html > > However, Bash introduced the option `-d ` to override IFS for > just one invocation, and it is quite useful. > > It is also super easy to implement in BusyBox' ash, so let's do that. > > The motivation: This option is used by Git's test suite. > > Signed-off-by: Johannes Schindelin Can you wrap the change within a macro conditional like #if BASH_READ_D ? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Silence misguided GCC warning about alignment issues
On Mon, Aug 7, 2017 at 10:37 PM, Emmanuel Deloget wrote: > > > > On Mon, Aug 7, 2017 at 9:46 PM, Johannes Schindelin > wrote: >> >> Hi Denys, >> >> On Mon, 7 Aug 2017, Denys Vlasenko wrote: >> >> > On Mon, Aug 7, 2017 at 12:09 PM, Johannes Schindelin >> > 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
[PATCH v2] Silence misguided GCC warning about alignment issues
When compiling xz_dec_stream.c with GCC (at least with versions 5.4.0 and 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)) ^~ Despite the arrow pointing to the xz_crc32() call, the actual problem is the get_le32() macro expansion. 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. An earlier attempt to fix (76b65624b (unxz: get_le32 macro is obviously wrong, 2017-08-07)) this by simply forcing get_unaligned_32() (which is unnecessarily slow because it rebuilds a 32-bit int from accessing already-aligned bytes one by one) was a bit heavy-handed. But we can help GCC by turning the get_le32() macro into an inline function. So let's do that, it also helps compile time safety by making the code a little bit stricter. Signed-off-by: Johannes Schindelin --- Published-As: https://github.com/dscho/busybox-w32/releases/tag/busybox-type-punned-warning-v2 Fetch-It-Via: git fetch https://github.com/dscho/busybox-w32 busybox-type-punned-warning-v2 Interdiff vs v1: diff --git a/archival/libarchive/decompress_unxz.c b/archival/libarchive/decompress_unxz.c index 0be85500c..e24cff98b 100644 --- a/archival/libarchive/decompress_unxz.c +++ b/archival/libarchive/decompress_unxz.c @@ -37,6 +37,11 @@ static uint32_t xz_crc32(const uint8_t *buf, size_t size, uint32_t crc) || !defined(put_unaligned_be32) # error get_unaligned_le32 accessors are not defined #endif +static ALWAYS_INLINE uint32_t get_le32_fast(const void *p) +{ + return *(uint32_t *)p; +} +#define get_le32 get_le32_fast #include "unxz/xz_dec_bcj.c" #include "unxz/xz_dec_lzma2.c" diff --git a/archival/libarchive/unxz/xz_dec_stream.c b/archival/libarchive/unxz/xz_dec_stream.c index 8131ee30a..bf791055b 100644 --- a/archival/libarchive/unxz/xz_dec_stream.c +++ b/archival/libarchive/unxz/xz_dec_stream.c @@ -423,15 +423,6 @@ static enum xz_ret XZ_FUNC dec_stream_footer(struct xz_dec *s) if (!memeq(s->temp.buf + 10, FOOTER_MAGIC, FOOTER_MAGIC_SIZE)) return XZ_DATA_ERROR; -#if defined(__GNUC__) - /* - * The temp.buf field is put just after two fields of type size_t for - * the express purpose of avoiding alignment issues. But GCC complains - * about it nevertheless... so: shut GCC up for a few lines. - */ -#pragma GCC diagnostic push -#pragma GCC diagnostic ignored "-Wstrict-aliasing" -#endif if (xz_crc32(s->temp.buf + 4, 6, 0) != get_le32(s->temp.buf)) return XZ_DATA_ERROR; @@ -442,9 +433,6 @@ static enum xz_ret XZ_FUNC dec_stream_footer(struct xz_dec *s) */ if ((s->index.size >> 2) != get_le32(s->temp.buf + 4)) return XZ_DATA_ERROR; -#if defined(__GNUC__) -#pragma GCC diagnostic pop -#endif if (s->temp.buf[8] != 0 || s->temp.buf[9] != s->check_type) return XZ_DATA_ERROR; archival/libarchive/decompress_unxz.c | 5 + 1 file changed, 5 insertions(+) diff --git a/archival/libarchive/decompress_unxz.c b/archival/libarchive/decompress_unxz.c index 0be85500c..e24cff98b 100644 --- a/archival/libarchive/decompress_unxz.c +++ b/archival/libarchive/decompress_unxz.c @@ -37,6 +37,11 @@ static uint32_t xz_crc32(const uint8_t *buf, size_t size, uint32_t crc) || !defined(put_unaligned_be32) # error get_unaligned_le32 accessors are not defined #endif +static ALWAYS_INLINE uint32_t get_le32_fast(const void *p) +{ + return *(uint32_t *)p; +} +#define get_le32 get_le32_fast #include "unxz/xz_dec_bcj.c" #include "unxz/xz_dec_lzma2.c" base-commit: a907b828d6e9f1357fc2e1db09d3eb1d3fb9b826 -- 2.14.0.windows.1.2.g0f3342804fc ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Silence misguided GCC warning about alignment issues
Hi Emmanuel, On Mon, 7 Aug 2017, Emmanuel Deloget wrote: > On Mon, Aug 7, 2017 at 12:25 PM, Lauri Kasanen wrote: > > On Mon, 7 Aug 2017 12:09:45 +0200 (CEST) > > Johannes Schindelin wrote: > >> Meaning: GCC gets this all wrong and should not complain. So let's force > >> it to be quiet for a couple of lines. > > > > I believe this is both wrong and dangerous. If gcc warns about it, it > > will also very likely try to mis-optimize the same case. > > > > - Lauri > > I tried to carefully read the code, and I don't see where the aliasing > issue migh be. > * buf is an uin8_t [] > * the code either use it as is, or promote it to const uint8_t *, or > cast it to (const) char *. > > All of these types are compatible w.r.t. aliasing (and the C99 > standard). I may have missed something though and my eyes might be > rusted. > > Now, it seems that some might have seen a regression in GCC with > respect to aliasing rules [1][2]. This might be an instance of the bug > (according to the bug report, it's no longer reproducible in GCC > trunk). I dug a little deeper, and it seems this issue may indeed have been reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 (and been fixed in the meantime). However... > Anyway, it might be a good idea to avoid unsetting the warning for one > buggy GCC version :) ... I get this warning *also* with the default GCC version of Ubuntu 16.04.3 LTS, gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609. So it is not just one buggy GCC version. I do agree, however, that it is a super-ugly patch, even if it does the job for the described purpose. So I set out to find a more elegant solution. More elegant, even, than removing the get_le32() macro as Denys did in 76b65624b (unxz: get_le32 macro is obviously wrong, 2017-08-07): the macro was there for a reason, namely to avoid accessing the (purposefully aligned) data using get_unaligned_le32() which is slow and unlikely to get optimized. It turns out that GCC simply has a hard time with the cast, without assigning the pointer explicitly to a variable. Turning get_le32() into an inline function lets GCC figure out that everything is groovy, and it also adds a bit more of concrete compile-time safety. I will send out v2 in a moment, assuming that Denys will agree that direct, provably aligned 32-bit access is better than an unnecessary assembly-from-individual-bytes. Ciao, Johannes ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Silence misguided GCC warning about alignment issues
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 > > 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. BR, -- Emmanuel Deloget ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Silence misguided GCC warning about alignment issues
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 > > 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
Re: [PATCH] Silence misguided GCC warning about alignment issues
Hi Denys, On Mon, 7 Aug 2017, Denys Vlasenko wrote: > On Mon, Aug 7, 2017 at 12:09 PM, Johannes Schindelin > 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
Re: [PATCH] Silence misguided GCC warning about alignment issues
On Mon, Aug 7, 2017 at 12:09 PM, Johannes Schindelin 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? ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Silence misguided GCC warning about alignment issues
Hello, On Mon, Aug 7, 2017 at 12:25 PM, Lauri Kasanen wrote: > On Mon, 7 Aug 2017 12:09:45 +0200 (CEST) > Johannes Schindelin wrote: >> Meaning: GCC gets this all wrong and should not complain. So let's force >> it to be quiet for a couple of lines. > > I believe this is both wrong and dangerous. If gcc warns about it, it > will also very likely try to mis-optimize the same case. > > - Lauri I tried to carefully read the code, and I don't see where the aliasing issue migh be. * buf is an uin8_t [] * the code either use it as is, or promote it to const uint8_t *, or cast it to (const) char *. All of these types are compatible w.r.t. aliasing (and the C99 standard). I may have missed something though and my eyes might be rusted. Now, it seems that some might have seen a regression in GCC with respect to aliasing rules [1][2]. This might be an instance of the bug (according to the bug report, it's no longer reproducible in GCC trunk). Anyway, it might be a good idea to avoid unsetting the warning for one buggy GCC version :) Best regards, -- Emmanuel Deloget [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80633 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Silence misguided GCC warning about alignment issues
On Mon, 7 Aug 2017 12:09:45 +0200 (CEST) Johannes Schindelin wrote: > Meaning: GCC gets this all wrong and should not complain. So let's force > it to be quiet for a couple of lines. I believe this is both wrong and dangerous. If gcc warns about it, it will also very likely try to mis-optimize the same case. - Lauri ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] ash/hush: implement -d DELIM option for `read`
The POSIX standard only requires the `read` builtin to handle `-r`: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html However, Bash introduced the option `-d ` to override IFS for just one invocation, and it is quite useful. It is also super easy to implement in BusyBox' ash, so let's do that. The motivation: This option is used by Git's test suite. Signed-off-by: Johannes Schindelin --- Published-As: https://github.com/dscho/busybox-w32/releases/tag/busybox-read-d-v1 Fetch-It-Via: git fetch https://github.com/dscho/busybox-w32 busybox-read-d-v1 shell/ash.c | 11 --- shell/hush.c | 7 +-- shell/shell_common.c | 10 +++--- shell/shell_common.h | 3 ++- 4 files changed, 22 insertions(+), 9 deletions(-) diff --git a/shell/ash.c b/shell/ash.c index e8f3ed26b..b4f6dc3df 100644 --- a/shell/ash.c +++ b/shell/ash.c @@ -13402,10 +13402,10 @@ letcmd(int argc UNUSED_PARAM, char **argv) * -p PROMPT Display PROMPT on stderr (if input is from tty) * -t SECONDS Timeout after SECONDS (tty or pipe only) * -u FD Read from given FD instead of fd 0 + * -d DELIMEnd on DELIM char, not newline * This uses unbuffered input, which may be avoidable in some cases. * TODO: bash also has: * -a ARRAYRead into array[0],[1],etc - * -d DELIMEnd on DELIM char, not newline * -e Use line editing (tty only) */ static int FAST_FUNC @@ -13415,11 +13415,12 @@ readcmd(int argc UNUSED_PARAM, char **argv UNUSED_PARAM) char *opt_p = NULL; char *opt_t = NULL; char *opt_u = NULL; + char *opt_d = NULL; int read_flags = 0; const char *r; int i; - while ((i = nextopt("p:u:rt:n:s")) != '\0') { + while ((i = nextopt("p:u:rt:n:sd:")) != '\0') { switch (i) { case 'p': opt_p = optionarg; @@ -13439,6 +13440,9 @@ readcmd(int argc UNUSED_PARAM, char **argv UNUSED_PARAM) case 'u': opt_u = optionarg; break; + case 'd': + opt_d = optionarg; + break; default: break; } @@ -13456,7 +13460,8 @@ readcmd(int argc UNUSED_PARAM, char **argv UNUSED_PARAM) opt_n, opt_p, opt_t, - opt_u + opt_u, + opt_d ); INT_ON; diff --git a/shell/hush.c b/shell/hush.c index bb80f422c..efa518a89 100644 --- a/shell/hush.c +++ b/shell/hush.c @@ -9434,13 +9434,15 @@ static int FAST_FUNC builtin_read(char **argv) char *opt_p = NULL; char *opt_t = NULL; char *opt_u = NULL; + char *opt_d = NULL; const char *ifs; int read_flags; /* "!": do not abort on errors. * Option string must start with "sr" to match BUILTIN_READ_xxx */ - read_flags = getopt32(argv, "!srn:p:t:u:", &opt_n, &opt_p, &opt_t, &opt_u); + read_flags = getopt32(argv, "!srn:p:t:u:d:", &opt_n, &opt_p, &opt_t, + &opt_u, &opt_d); if (read_flags == (uint32_t)-1) return EXIT_FAILURE; argv += optind; @@ -9454,7 +9456,8 @@ static int FAST_FUNC builtin_read(char **argv) opt_n, opt_p, opt_t, - opt_u + opt_u, + opt_d ); if ((uintptr_t)r == 1 && errno == EINTR) { diff --git a/shell/shell_common.c b/shell/shell_common.c index a9f8d8413..2db8ea3e2 100644 --- a/shell/shell_common.c +++ b/shell/shell_common.c @@ -54,7 +54,8 @@ shell_builtin_read(void FAST_FUNC (*setvar)(const char *name, const char *val), const char *opt_n, const char *opt_p, const char *opt_t, - const char *opt_u + const char *opt_u, + const char *opt_d ) { struct pollfd pfd[1]; @@ -237,14 +238,17 @@ shell_builtin_read(void FAST_FUNC (*setvar)(const char *name, const char *val), continue; } } - if (c == '\n') + if (opt_d) { + if (c == *opt_d) + break; + } else if (c == '\n') break; /* $IFS splitting. NOT done if we run "read" * without variable names (bash compat). * Thus, "read" and "read REPLY" are not the same. */ - if (argv[0]) { + if (!opt_d && argv[0]) { /* http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_05 */ const char *is_ifs = strchr(ifs, c); if (startword && is_ifs) { diff --git a/shell/shell_common.h b/shell/shell_common.h index a82535c86..1b79bf
[PATCH] Silence misguided GCC warning about alignment issues
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. Signed-off-by: Johannes Schindelin --- archival/libarchive/unxz/xz_dec_stream.c | 12 1 file changed, 12 insertions(+) diff --git a/archival/libarchive/unxz/xz_dec_stream.c b/archival/libarchive/unxz/xz_dec_stream.c index bf791055b..8131ee30a 100644 --- a/archival/libarchive/unxz/xz_dec_stream.c +++ b/archival/libarchive/unxz/xz_dec_stream.c @@ -423,6 +423,15 @@ static enum xz_ret XZ_FUNC dec_stream_footer(struct xz_dec *s) if (!memeq(s->temp.buf + 10, FOOTER_MAGIC, FOOTER_MAGIC_SIZE)) return XZ_DATA_ERROR; +#if defined(__GNUC__) + /* +* The temp.buf field is put just after two fields of type size_t for +* the express purpose of avoiding alignment issues. But GCC complains +* about it nevertheless... so: shut GCC up for a few lines. +*/ +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wstrict-aliasing" +#endif if (xz_crc32(s->temp.buf + 4, 6, 0) != get_le32(s->temp.buf)) return XZ_DATA_ERROR; @@ -433,6 +442,9 @@ static enum xz_ret XZ_FUNC dec_stream_footer(struct xz_dec *s) */ if ((s->index.size >> 2) != get_le32(s->temp.buf + 4)) return XZ_DATA_ERROR; +#if defined(__GNUC__) +#pragma GCC diagnostic pop +#endif if (s->temp.buf[8] != 0 || s->temp.buf[9] != s->check_type) return XZ_DATA_ERROR; base-commit: 4dea1edd08a45c5987448719e56ee61a20fb9210 -- 2.14.0.windows.1.2.g0f3342804fc Published-As: https://github.com/dscho/busybox-w32/releases/tag/busybox-type-punned-warning-v1 Fetch-It-Via: git fetch https://github.com/dscho/busybox-w32 busybox-type-punned-warning-v1 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox