From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12622 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: #define __MUSL__ in features.h Date: Thu, 15 Mar 2018 15:42:05 -0400 Message-ID: <20180315194205.GM1436@brightrain.aerifal.cx> References: <20180315183939.GI1436@brightrain.aerifal.cx> <20180315185358.GJ1436@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 1521142834 20675 195.159.176.226 (15 Mar 2018 19:40:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Mar 2018 19:40:34 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12636-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 15 20:40:30 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 1ewYjm-0005IY-9i for gllmg-musl@m.gmane.org; Thu, 15 Mar 2018 20:40:30 +0100 Original-Received: (qmail 3181 invoked by uid 550); 15 Mar 2018 19:42:21 -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 3083 invoked from network); 15 Mar 2018 19:42:17 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12622 Archived-At: On Thu, Mar 15, 2018 at 04:13:44PM -0300, dgutson . wrote: > 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. musl does not comply or aim to comply with MISRA. MISRA certainly has a place, as a set of very strict practices that you can verify with static checks and that force you to be very explicit about things that might not be obvious to programmers not really familiar with C. But it also makes C much more verbose and hard to read if you are familiar with the language. I don't fault people/orgs using MISRA for doing safety-critical embedded work that has to be done in C, but I don't want to be the one dealing with it. Rich