public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel@rtems.org>
Cc: newlib@sourceware.org
Subject: Re: -Wall
Date: Fri, 19 Jan 2024 09:55:21 -0600	[thread overview]
Message-ID: <CAF9ehCVa4tt9vm58oDoK=nydiCouDWaMZ2vtXHHj5FOqRPpjBA@mail.gmail.com> (raw)
In-Reply-To: <ZaqXgRDsH3lchs48@vapier>

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

On Fri, Jan 19, 2024 at 9:39 AM Mike Frysinger <vapier@gentoo.org> wrote:

> On 19 Jan 2024 13:55, Corinna Vinschen wrote:
> > if you saw my today's pushes, you're aware that I only found a bug
> > because I used -Wall.  I fixed the bug and a few less crucial warnings.
> >
> > I did NOT fix the warnings in code we took verbatim from some BSDs,
> > which often contain unused variables, or in some cases expressions which
> > are deemed to profit from extra paranthesis, e. g.
> >
> >   if (a >= 0 ^ b == 0)
> >
> > For that reason, I'd like to suggest to add -Wall by default to the
> > build flags for newlib, just as it is already for ages in the Cygwin
> > tree.
> >
> > Anybody having a strong opinion, pro or contra?
>
> enabling -Wall by default sounds fine.  if you wanted to include any
> -Werror,
> that would require more effort/tooling like putting it all behind a new
> flag
> like --enable-werror.
>

Based on the warnings from BSD code, I hope you think -Werror should be
off by default until the warnings are cleaned up.

For RTEMS, we try not to modify code imported from third parties. We have
a rule that you can only add code inside an ifdef __rtems__. For example,
if
we wanted to eliminate those unused variable warnings, we would likely do
something like this in third party code:

#ifndef __rtems__
  int unused_variable;
#endif

And, if being really diligent, post a patch or ticket to the upstream
project.
Our goal is to make it easier to update these files in the future.

FWIW we have over 1M lines of FreeBSD code in rtems-libbsd which is
a port of the FreeBSD networking, USB, nvme, etc. and the commands
to configure the stack (ifconfig, route, netstat, ping, etc) This has worked
pretty well for us.

--joel


> -mike
>

  reply	other threads:[~2024-01-19 15:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-19 12:55 -Wall Corinna Vinschen
2024-01-19 15:38 ` -Wall Mike Frysinger
2024-01-19 15:55   ` Joel Sherrill [this message]
2024-01-19 16:23 ` -Wall Liviu Ionescu
2024-01-19 18:34   ` -Wall Liviu Ionescu
2024-01-20 18:17 ` -Wall brian.inglis
2024-01-24  5:38   ` -Wall brian.inglis
2024-01-24 11:19     ` -Wall Corinna Vinschen
2024-01-24 11:25       ` -Wall Liviu Ionescu
2024-01-24 13:06         ` -Wall Corinna Vinschen
2024-01-21 11:41 ` -Wall Liviu Ionescu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF9ehCVa4tt9vm58oDoK=nydiCouDWaMZ2vtXHHj5FOqRPpjBA@mail.gmail.com' \
    --to=joel@rtems.org \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).