Date: Thu, 15 Mar 2018 16:00:37 -0300 From: "dgutson ." <danielgutson@...il.com> To: musl@...ts.openwall.com Subject: Re: Re: #define __MUSL__ in features.h On Thu, Mar 15, 2018 at 3:53 PM, Rich Felker <dalias@...c.org> wrote: > On Thu, Mar 15, 2018 at 03:48:32PM -0300, Martin Galvan wrote: > > 2018-03-15 15:39 GMT-03:00 Rich Felker <dalias@...c.org>: > > >> (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 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? Content of type "text/html" skipped
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.