public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Liviu Ionescu <ilg@livius.net>
To: newlib@sourceware.org
Subject: Re: -Wall
Date: Fri, 19 Jan 2024 18:23:04 +0200	[thread overview]
Message-ID: <42301155-A500-4FEC-B075-83C7D28500ED@livius.net> (raw)
In-Reply-To: <ZapxLOLazU-oWKIS@calimero.vinschen.de>



> On 19 Jan 2024, at 14:55, Corinna Vinschen <vinschen@redhat.com> wrote:
> 
> ... 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?

For my own code I run all tests with `-Werror -Wall` and as many extra `-fxxx` options I can (trying to emulate the LLVM/clang `-feverything`). This usually requires a combination of code edits and pragmas to silence some warnings, which may be tedious, but it gives me some peace of mind when my code is integrated in various build environments.

However, when I make binary distributions using someone else code (*), I find compiler warnings less useful (read annoying), since there is not much I can do to fix them.

For the newlib configure, if not already available, I suggest you implement `--enable-warnings`/`--disable-warnings` and `--enable-werror`/`--disable-werror`.

The default are usually disabled, but are not that relevant; for my builds I generally use explicit `--disable-warnings --disable-werror` when available.

But for your CI tests, sure, enable `-Wall` and try to fix the code to clear all warnings, using the latest toolchains.


Regards,

Liviu


(*) I maintain the xPack binary cross-platform distributions of arm-none-eabi-gcc and riscv-none-elf-gcc, which also include newlib.


  parent reply	other threads:[~2024-01-19 16:23 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   ` -Wall Joel Sherrill
2024-01-19 16:23 ` Liviu Ionescu [this message]
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=42301155-A500-4FEC-B075-83C7D28500ED@livius.net \
    --to=ilg@livius.net \
    --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).