[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEzKa92sOgkeijjnogjrFBF+BxiEbR3cuP1RexRR6OpFUguvcw@mail.gmail.com>
Date: Thu, 2 Aug 2018 13:51:21 -0400
From: Jonny Prouty <jonathanprouty@...il.com>
To: musl@...ts.openwall.com
Subject: Unexpected behaviour writing to /dev/full
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.
Content of type "text/html" skipped
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.
