From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13097 Path: news.gmane.org!.POSTED!not-for-mail From: Jonny Prouty Newsgroups: gmane.linux.lib.musl.general Subject: Unexpected behaviour writing to /dev/full Date: Thu, 2 Aug 2018 13:51:21 -0400 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002ed8fc0572777675" X-Trace: blaine.gmane.org 1533232490 6247 195.159.176.226 (2 Aug 2018 17:54:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2018 17:54:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-13113-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 02 19:54:46 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1flHoD-0001Xb-9C for gllmg-musl@m.gmane.org; Thu, 02 Aug 2018 19:54:45 +0200 Original-Received: (qmail 32592 invoked by uid 550); 2 Aug 2018 17:56:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26393 invoked from network); 2 Aug 2018 17:51:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5o0WG4CM3b4D8Ycl9jGPMN19YknDLhih+9uOsxkZTt4=; b=ekyc4Mz2xwfNZ5+fyvqtJLi7GpguZ+XQNrrYKS9yRGgpM3NzYjBoJNiStecw4eH9yU 4OxTNJ/phVa8HWtADX5FM6iS5QdJxUHWsh9442FqcSAzK3w6FhBjD8IARVsUX+MHG5lD CjBHnTFixA6RdAzGNc1AcAm9cBfZ03GfhRCBBmaqZTkxNxDO/4n/qEJ8eREClQdxAuO8 jRXWgbaODWKr8dHk/dMaOGaXoi29zN539H98ey3hG57DYIBb23MAfTQJZiqKDECdiHMd 0pmr4pVZs5jtYneYkUZeeeLp6ib0ra04Ux/vibUjTYOaS7Cn3nNS05qdusglELyeq6sf pTjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5o0WG4CM3b4D8Ycl9jGPMN19YknDLhih+9uOsxkZTt4=; b=YYCat8miv35qtOrlZSpTi5Fv/4kvumRRwBTN++LiWzTZlVkSY2eJjjZ2LW/SEGfRlo OHNaVOl7aOWMSgqXGWUaEuOP2TS4+b690WtxuW+hWmkY3X/kOnUTL6DRQOKEzvzdpQBo Bldb8Nho1w3xJJGazjLGDTg65cq0jdxAmMMuv8VFBEPcltZNEN64RWRBqbCkWy49DU6z d8w/EtF6K5StfLogHDe3v43h3O3Ow/VSWMPZLysOzOGJKPQDaz7r9ySuMRJyv8g6mUv2 H1hHswxuaxuNhgv6b+dcLGa82xt3tCsxEK8Y4r9xG/JIqCawDn6lFDKk83k1zupCrhqa aoWw== X-Gm-Message-State: AOUpUlExylE3nY+hTBz+rn0nZSvt4M8N8W3H6d4aAfRpQIySRA+6+Nr6 11FCGmJDgYAUdZayZoT6oCvV4FzglMtvR1Yc6oMsVw== X-Google-Smtp-Source: AAOMgpea4P92f7wVfeb1hSiZBhw82BQDS2v5VJd+eX1TYiVpUgflON37Trn1oxV4o0BZLFevomESuSQn8wlsZeU/NGU= X-Received: by 2002:a19:4c57:: with SMTP id z84-v6mr2393287lfa.67.1533232293007; Thu, 02 Aug 2018 10:51:33 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:13097 Archived-At: --0000000000002ed8fc0572777675 Content-Type: text/plain; charset="UTF-8" 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. --0000000000002ed8fc0572777675 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

<= /div>
I have a question regarding the interaction of atexi= t() (I believe its atexit, anyways) and exit statuses. First the issue I st= umbled across, so you'll see where I'm coming from:

# ls "$HOME" > /dev/full= ; echo $?
0
# echo "$HOM= E" > /dev/full; echo $?
1

I expected neither command to return 0 sin= ce ultimately an ENOSPC should be returned when writing to /dev/full. Indee= d, failure statuses are returned for 'ls' and 'echo' derive= d from binaries built against glibc. I tried to walk the musl code and it l= ooks like the exit codes are being set (or not set) by atexit(). In the cas= e of 'ls', it seems that it was able to successfully get a director= y listing, but the final fflush() of the output buffer fails with ENOSPC, b= ut that is lost because it happened as a result of some function that was r= egistered with atexit. I *think*. This interpretation is also borne of a de= sire to be able to ascribe this to the undefined re-entrant exit behaviour = described in "Re-entrancy of exit" at https://wiki.musl-libc.o= rg/functional-differences-from-glibc.html. 'echo' would be fail= ing (as expected) because presumably stdout is flushed before it exits.

Regardless, the fact that w= riting to /dev/full can return success seems wrong. Any thoughts are much a= ppreciated. Please CC me on any responses. Thanks!
<= br>
Jonny

P.S.
musl behaves similarly to uClibc and = uClibc-ng in my testing.
--0000000000002ed8fc0572777675--