Date: Sat, 9 Jan 2016 01:39:10 +0300 From: Alexander Cherepanov <ch3root@...nwall.com> To: musl@...ts.openwall.com Subject: Re: string word-at-a-time and atomic.h FAQ on twitter On 2016-01-09 01:05, Rich Felker wrote: > On Sat, Jan 09, 2016 at 12:59:55AM +0300, Alexander Cherepanov wrote: >> On 2016-01-05 20:50, Rich Felker wrote: >>> So we could just consider trying to drop the OOB >>> accesses. Do we have a list of affected functions? That might be nice >>> to include. >> >> I think it would be nice to have a full list of intentional UB. For >> example, this: >> >> http://git.musl-libc.org/cgit/musl/tree/src/stdio/vsnprintf.c#n33 >> >> if (n > (char *)0+SIZE_MAX-s-1) n = (char *)0+SIZE_MAX-s-1; >> >> If I understand the code correctly, fixing it will require changes >> to the FILE structure. Are there such plans? > > Fixing it requires not just changes to the structure, but abandoning > compatibility with buffer reads and writes via the glibc ABI (used by > glibc getc_unlocked and putc_unlocked macros). This is not as bad as > it sounds; if we just abandoned use of the glibc-offset-defined fields > and made them always null pointers, then legacy glibc code would > always see no buffer available and make a function call instead. I'm > not clear on whether this might break code using the gnulib junk that > pokes at glibc FILE internals, though, or whether such code works now, > nor am I clear whether we even care. Ugh. Documenting UB in it in the mean time seems like non-controversial thing:-) >>>> this takes care of oob access, but the bytes outside the passed >>>> object might change concurrently i.e. strlen might introduce a >>>> data race: again this is a problem on the abstract c language >>>> level that may be solved e.g. by making all accesses to those >>>> bytes relaxed atomic, but user code is not under libc control. >>>> in practice the code works if HASZERO reads the word once so it >>>> does arithmetics with a consistent value (because the memory >>>> model of the underlying machine does not treat such race >>>> undefined and it does not propagate unspecified value bits nor >>>> has trap representations). >>> >>> Indeed, this seems like less of a practical concern. >> >> HASZERO reads the word twice so this should be a problem for >> unoptimized code on big-endian platforms. > > The number of abstract-machine reads is irrelevant unless we use > volatile here. A good compiler will always reduce it to one read, and > a bad compiler is always free to turn it into multiple reads. Ok, I'll reformulate: is compiling musl on a big-endian platform with optimizations turned off officially supported? -- Alexander Cherepanov
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.