Re: [PATCH] ash/hush: implement -d DELIM option for `read`

[Kang-Che Sung]

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

[Emmanuel Deloget]

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

[Johannes Schindelin]

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

[Johannes Schindelin]

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

[Emmanuel Deloget]

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

[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
> >  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

[Johannes Schindelin]

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

[Denys Vlasenko]

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

[Emmanuel Deloget]

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

[Lauri Kasanen]

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`

[Johannes Schindelin]

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:", _n, _p, _t, 
_u);
+   read_flags = getopt32(argv, "!srn:p:t:u:d:", _n, _p, _t,
+   _u, _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..1b79bffca 

[PATCH] Silence misguided GCC warning about alignment issues

[Johannes Schindelin]

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