[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180802180306.GL1392@brightrain.aerifal.cx>
Date: Thu, 2 Aug 2018 14:03:06 -0400
From: Rich Felker <dalias@...c.org>
To: Jonny Prouty <jonathanprouty@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Unexpected behaviour writing to /dev/full
On Thu, Aug 02, 2018 at 01:51:21PM -0400, Jonny Prouty wrote:
> Hello all,
>
> I have a question regarding the interaction of atexit() (I believe its
> atexit, anyways) and exit statuses. First the issue I stumbled across, so
> you'll see where I'm coming from:
>
> # ls "$HOME" > /dev/full; echo $?
> 0
> # echo "$HOME" > /dev/full; echo $?
> 1
>
> I expected neither command to return 0 since ultimately an ENOSPC should be
> returned when writing to /dev/full. Indeed, failure statuses are returned
> for 'ls' and 'echo' derived from binaries built against glibc. I tried to
> walk the musl code and it looks like the exit codes are being set (or not
> set) by atexit(). In the case of 'ls', it seems that it was able to
> successfully get a directory listing, but the final fflush() of the output
> buffer fails with ENOSPC, but that is lost because it happened as a result
> of some function that was registered with atexit. I *think*. This
> interpretation is also borne of a desire to be able to ascribe this to the
> undefined re-entrant exit behaviour described in "Re-entrancy of exit" at
> https://wiki.musl-libc.org/functional-differences-from-glibc.html. 'echo'
> would be failing (as expected) because presumably stdout is flushed before
> it exits.
>
> Regardless, the fact that writing to /dev/full can return success seems
> wrong. Any thoughts are much appreciated. Please CC me on any responses.
> Thanks!
>
> Jonny
>
> P.S.
> musl behaves similarly to uClibc and uClibc-ng in my testing.
What versions of ls and echo are you using? Busybox? GNU coreutils?
(Note that echo is probably a shell builtin in your shell; you need to
execute /bin/echo or similar to get the real echo program.)
There is nothing musl can do directly to change the exit status;
failure when writing/flushing a file is an error returned to the
application, which determines its own exit status, not something that
automatically changes the return value of main/argument passed to
exit().
Do you mean the program is trying to detect flush failure and set an
exit status from an atexit handler it installed? That's what gnulib
stuff does, if I recall, and it may be how the GNU coreutils ls and
other programs handle termination status. It's not a very good way to
do it, but it should work if they're doing things right. If they're
doing something that's unspecified or undefined from the atexit
handler, such as calling exit again (reentrantly), that's an
application bug.
If you tell us which versions of the utilities you're using, I can
look into it a bit more.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
