Re: string-backed FILEs mess

[Markus Wichmann <nullplan@gmx.net>]

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