On Thu, Mar 15, 2018 at 4:00 PM, dgutson . wrote: > > > On Thu, Mar 15, 2018 at 3:53 PM, Rich Felker wrote: > >> On Thu, Mar 15, 2018 at 03:48:32PM -0300, Martin Galvan wrote: >> > 2018-03-15 15:39 GMT-03:00 Rich Felker : >> > >> (e.g. the FD* issue reported by Martin Galvan). >> > > >> > > That's not a bug. It's compiler warnings being wrongly produced for a >> > > system header, probably because someone added -I/usr/include or >> > > similar (normally GCC suppresses these). >> > >> > I'm certain we didn't add -I/usr/include or something similar. Could >> > you test this yourself to confirm it's not a bug? >> >> In any case it's not a bug in musl. The code is perfectly valid C. If >> the compiler is producing a warning for it, either ignore it or ask >> the compiler to stop. >> >> > The compiler warnings aren't being wrongly produced. musl will indeed >> > perform a signed-to-unsigned conversion here. >> >> Because that's how the C language works. >> > > it is a potential vulnerability: > https://cwe.mitre.org/data/definitions/195.html > https://wiki.sei.cmu.edu/confluence/display/c/INT31-C.+ > Ensure+that+integer+conversions+do+not+result+in+ > lost+or+misinterpreted+data > https://wiki.sei.cmu.edu/confluence/display/c/INT30-C.+ > Ensure+that+unsigned+integer+operations+do+not+wrap > Just to add: the code doesn't not comply with MISRA 2004 because it violates 6.10.3. IOW, at least this issue turns musl MISRA non-compliant. > > > Can you ensure it is rocksolid and the signed integer will NEVER be a > negative value? > > >> >> > > The musl policy regarding not having a macro like __MUSL__ is doing >> > > exactly what it's intended to do: encouraging developers and package >> > > maintainers to come to us (or investigate on their own) and fix the >> > > underlying portability problems (and sometimes musl bugs) rather than >> > > writing hacks to a specific version of musl that will be wrong a few >> > > versions later. >> > >> > So whenever we find a bug on musl we should just stop all our >> > development until you've fixed the bug? >> >> No. As noted above, if you need to support systems that might have bug >> X, you write a test (configure-time or run-time as appropriate) to >> detect bug X and handle it. >> >> Rich >> > > > > -- > Who’s got the sweetest disposition? > One guess, that’s who? > Who’d never, ever start an argument? > Who never shows a bit of temperament? > Who's never wrong but always right? > Who'd never dream of starting a fight? > Who get stuck with all the bad luck? > -- Who’s got the sweetest disposition? One guess, that’s who? Who’d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck?