public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug general/23914] Add --disable-werror to ./configure support (example trigger:  CFLAGS=-Og
Date: Wed, 28 Nov 2018 13:41:00 -0000	[thread overview]
Message-ID: <bug-23914-10460-HNTzBZiqkG@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-23914-10460@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=23914

--- Comment #3 from Mark Wielaard <mark at klomp dot org> ---
(In reply to Sergei Trofimovich from comment #2)
> Gentoo allows users to control CC and CFLAGS and thus the space for getting
> a warning is wide. People frequently use things like -Wcast-qual or other
> high signal-to-noise flags for their purposes.

If they do and don't care about the warnings, then why don't they simply add
-Wno-error too?

> My favourite example is
>     ./configure CFLAGS="-g -Wall" # works today without failures
> or even ./configure CC=clang CFLAGS="-g -Weverything" but elfutils does not
> seem to support clang.

Yes, -Wall is one of the warnings we explicitly enable. See config/eu.am for
the full list. Some have configure checks to make sure the compiler actually
supports it. And some sadly have to be disabled for some specific source files.
If you have concrete warning flags you would like to see enabled by default
please do submit them, but we do like to enable them only once the code base is
clean. Then we enable them by default and will always catch whenever new code
produces a warning (because of -Werror).

An -Weverything flag seems silly, some warnings don't really mix, some are for
style issues. IMHO warnings are only interesting if you can take some action to
correct the code.

clang support would be nice, but clang doesn't support various GNU C
extensions, there is a configure check for it though, so as soon as clang
actually support -std=gnu99 it should work.

> Real-world examples used by people:
> 
> 1. CFLAGS="-g -Wall -Wcast-qual"
> 
>   In file included from gelf_xlate.c:166:
>   version_xlate.h: In function 'elf_cvt_Verdef':
>   version_xlate.h:74:31: error: cast discards 'const' qualifier from pointer
> target type [-Werror=cast-qual]
>          dsrc = (GElf_Verdef *) ((char *) src + def_offset);
>                                  ^

There are a lot of cast-qual warnings. It might make sense to clean them up.
But it might be hard since in some cases we support overlapping src/dest
buffers which might be marked "wrongly" in the external API.

> 2. CFLAGS="-g -O2 -Wstack-protector"
> 
>     CC       readelf.o
>   readelf.c: In function 'open_input_section':
>   readelf.c:581:1: error: stack protector not protecting local variables:
> variable length buffer [-Werror=stack-protector]
>    open_input_section (int fd)
>    ^~~~~~~~~~~~~~~~~~

That in itself wouldn't warn. I assume you are using
-fstack-protector[-all|strong] too.

The warning is correct. We do already support -Wstack-usage. But it is disabled
for a couple of files. readelf.c is one of them (see src/Makefile.am).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  parent reply	other threads:[~2018-11-28 13:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-23 16:29 [Bug general/23914] New: " slyfox at inbox dot ru
2018-11-23 20:25 ` [Bug general/23914] " mark at klomp dot org
2018-11-23 23:42 ` slyfox at inbox dot ru
2018-11-28 13:41 ` mark at klomp dot org [this message]
2018-12-02 23:41 ` slyfox at inbox dot ru

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=bug-23914-10460-HNTzBZiqkG@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=elfutils-devel@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).