From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13234 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: string-backed FILEs mess Date: Wed, 12 Sep 2018 19:41:12 +0200 Message-ID: <20180912174112.GC13976@voyager> References: <20180912140239.GV1878@brightrain.aerifal.cx> <20180912150941.GB13976@voyager> <20180912154306.GW1878@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1536773968 12274 195.159.176.226 (12 Sep 2018 17:39:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Sep 2018 17:39:28 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13250-gllmg-musl=m.gmane.org@lists.openwall.com Wed Sep 12 19:39:24 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 1g096q-00037N-3c for gllmg-musl@m.gmane.org; Wed, 12 Sep 2018 19:39:24 +0200 Original-Received: (qmail 7814 invoked by uid 550); 12 Sep 2018 17:41:33 -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 7796 invoked from network); 12 Sep 2018 17:41:32 -0000 Content-Disposition: inline In-Reply-To: <20180912154306.GW1878@brightrain.aerifal.cx> X-Provags-ID: V03:K1:GlVD49sRhbjKCuJbOciOiiLB70XbWTW7jQ5G8uUsUhTTVrpA9GF vUPSbPZBM4y0YaharVyt/AxdZeqle2huVRayX98UOH3mFucCrfvfzpZ1S8OKQA5yrB/f4rX wI4dkc5SLfZ3T/dS+veu9azHcj1H+EceyL3CloLquZXsa4r1HIUQ0QFiHj+U2u8T5ZVQLUa A6W8k4o6H3KWMqSgZLX3Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:pD9TZbHNDxU=:Q9jTTsMSFpsebgCNvg0MK+ vHj/GM0UGDtrMfkXX17q0Fg3/IDU0LtUk/NZLpiCAyQSwFQ6BmpSX64IMQVva21a5t9Kvc9NF XxPILxxjl64D0f6gDbwQsMHkce7rBPc2s25klTNj4eKG3zYrEngVI2ux3ttHSdoqKNXrGEz8A 0afXPBnIM1bxdjcRGc15YEbpZJaf4VwXTB489R8m3yJXv5TZzsm1Xdv2Nq7HMN7VChBg6SLfV lNaLKlnWe5z/yTgmNVssN0y7qMg38n0gootacD11L4b1b/Ch9kDDws8YSg4Xc8GtU19+vVjfn ctc6+OikyHQHH8u2PTVZKN9Oxns9sCRuWkRJW5HQpU/7/K5EkfQ+bEUnRjc/eHYYrV50YUxHl zj3l9IoMZKOCfkOOkgfp51ARCGt9b3N5O5R7CRKQ8DbhgCQfjtHN0XM4Y1xvjYdcpfOzbfjh+ YSzYmpnT0JNyfsIyl/rlrOf6V8ol7NSpT8b1IrmCEdU2y2MdfM++7cRY7O1qF58m5WKWOkwKy zmTSD3q18CA5TlqAFa8nVGhlr5cjxVm+V5v4rVKzndrYVRiy1BVE6sJibzgYb83BQvGEDYamv gWZz8SKK3t1DOSvVnbGWEvbcwnvYs1aTX4oaiZ7Q+1IW63a3YV2NfXMXtcLMoEUK9xILgn0/R I3Y12WajyxcPEOBHGSXJfk4/gupA87O548DV7DbQxly1RQJa508PKpUyQUTZ8Bxljnpktb27b wPm5Ga/FTieYOaU5uqjpUlbH0RZaUp0OVz6CbEm4ozKf7H0jG0aGUIGIA5/qUkHYdBEXDO8i Xref: news.gmane.org gmane.linux.lib.musl.general:13234 Archived-At: On Wed, Sep 12, 2018 at 11:43:06AM -0400, Rich Felker wrote: > On Wed, Sep 12, 2018 at 05:09:41PM +0200, Markus Wichmann wrote: > > Well, first of all, I might set my foot wrong here very badly, but I > > generally don't care about C standard UB as long as the behavior is > > defined elsewhere. > > Like where? In order for it to be defined, the *compiler* has to > define it, since otherwise it can make transformations that assume the > behavior is undefined. So what you're asking for here is basically > amounting to only supporting certain compilers (with certain flags), > and notably *not supporting* UBSan, which is a really valuable tool > for catching bugs. > Oh, I didn't think of that. But the compiler still has to follow the ABI, and the ABI says we have linear addresses. So the pointer to integer mapping still has to work, and (void*)-1 is defined in the SysV ABI. Wouldn't make much sense for DOS, but hey, that's not a supported platform. (Actually that's a bad example, because it would totally make sense as the far pointer to FFFF:FFFF, but you get my point.) Besides, you're opening a very scary door there: The C standard's chapter 7 contains a whole lot of UB in the library, and a compiler writer could now say: Since it is undefined, obviously it is never going to happen (and if it does, it is your own fault), so I can write the optimizer to assume all arguments to functions are such that UB does not occur. The standard says fflush() is only defined for output streams, so we're going to assume any stream passed into fflush() is an output stream and... I don't know, assume all input functions are going to fail until the next fseek()? Actually, I'm drawing a blank as to what they could do with this, but the GCC folks would find a way to mess with my code. As for UBSan: Can't these sanitizers get their fingers out of the system implementation? That is pretty much the reason why warnings are suppressed for system header files, after all: Sometimes, the implementation just does things you're not supposed to. Like casting -1 to void*. Or calling free() on random pointers that weren't produced by malloc() before. But the implementation can do these things because it knows things a portable program can't know. > > Rich Ciao, Markus