Changing policy about -Werror

classic Classic list List threaded Threaded
119 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: acceptable alternatives to -Werror, was: Changing policy about -Werror

Rich Freeman
On Wed, Sep 12, 2018 at 8:23 PM Chí-Thanh Christopher Nguyễn
<[hidden email]> wrote:

>
> Rich Freeman schrieb:
> >> Requirements:
> >>
> >> * Do not fail to build/install when a warning is encountered
> >
> > On a particularly critical package like a filesystem, wouldn't we want
> > to still fail to install when a warning is encountered?
>
> Installation will proceed, but the user will get a big fat warning that the
> sys-fs/zfs package is potentially broken.
>
> > I get that users might quit if packages don't install, but I'm not
> > sure that a filesystem corruption is going to make them any happier...
>
> If the user recognizes this as a critical package, then they can do the
> research before deciding on whether to use the package as is, attempt to
> downgrade, or wait until a fix is released.

But, you've ALREADY overwritten the previous version of the package
that presumably didn't have this problem.  What if downgrading doesn't
cause the problem to go away?  What if it is due to some dependency or
toolchain change?  Users would presumably want to roll back to the
binaries that were working just a few minutes ago, not build new ones
that might or might not have the same issue.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: acceptable alternatives to -Werror, was: Changing policy about -Werror

Chí-Thanh Christopher Nguyễn
Rich Freeman schrieb:

>> If the user recognizes this as a critical package, then they can do the
>> research before deciding on whether to use the package as is, attempt to
>> downgrade, or wait until a fix is released.
>
> But, you've ALREADY overwritten the previous version of the package
> that presumably didn't have this problem.  What if downgrading doesn't
> cause the problem to go away?  What if it is due to some dependency or
> toolchain change?  Users would presumably want to roll back to the
> binaries that were working just a few minutes ago, not build new ones
> that might or might not have the same issue.

Users could weigh their options and then decide on how to best proceed. In
case of zfs, they still have time until next reboot to fix this.

Or the maintainer can set PROPERTIES="interactive" in anticipation of such a
situation and ask "Are you sure you want to install this [y/N]?".


Best regards,
Chí-Thanh Christopher Nguyễn

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Matt Turner-5
In reply to this post by Rich Freeman
On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman <[hidden email]> wrote:

>
> On Wed, Sep 12, 2018 at 7:52 PM Matt Turner <[hidden email]> wrote:
> >
> > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman <[hidden email]> wrote:
> > > Now, I could buy that -Werror turns NEW warnings into fatal errors,
> > > due to the use of a newer toolchain, since upstream probably didn't
> > > test with that toolchain and thus wouldn't have seen the warning.
> >
> > Yes, exactly. This is one of the major things people have said repeatedly.
> >
> > Werror makes moving gcc forward much more difficult.
> >
>
> Sure, but wouldn't a block on newer versions of gcc cause similar headaches?

Sure...? Who is suggesting that? I'm not sure where you're going with this.

With new GCC comes new warnings, and harmless as the vast majority are
they cause the build to break with Werror.

Reply | Threaded
Open this post in threaded view
|

Re: acceptable alternatives to -Werror, was: Changing policy about -Werror

Mike Auty-3
In reply to this post by Chí-Thanh Christopher Nguyễn
Hiya,

On 13/09/2018 01:23, Chí-Thanh Christopher Nguyễn wrote:
> Installation will proceed, but the user will get a big fat warning that
> the sys-fs/zfs package is potentially broken.

This seems like a sure-fire way to make users paranoid and/or
desensitized?  People will learn to ignore warnings if we make them big
red and flashing but then say they're only potential breakages (and they
subsequently discover that most everything runs fine).  If they learn to
ignore big red flashing warnings it'll be more difficult when they're
not potential breakages but actual ones we've accurately identified...

Mike  5:)


signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Ulrich Mueller-2
In reply to this post by Mike Pagano
>>>>> On Wed, 12 Sep 2018, Mike  wrote:

> Picking random email.

> I would like to say I'm glad we can discuss our technical differences
> like this with both sides expressing their opinion and reasoning.

> I would hope in the future we start with this path and not with
> disciplinary action or bugs requesting the removal of commit access.

> We're showing here we can bring up our points without handing out "QA
> strikes" or some other type of confrontational action.

Sorry, but I am tired of that antagonising of the QA team.

There hasn't been any bug about commit access removal. And not sure what
you mean with "QA strike", but there also wasn't any direct QA action on
the package that triggered the current discussion. After being CCed to a
bug, the QA team has merely pointed out to the maintainer that the
package is not in agreement with the current policy (as it is defined in
the devmanual).

IMHO this is the QA team's purpose. Or what would you expect us to do
instead? Remain silent if asked by another developer to evaluate an
issue? Then we could as well disband QA.

Also note that there are several remedies if there is disagreement
between a maintainer and QA, like asking QA for an exception, appealing
to the council, or changing the policy in question.

Ulrich

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Richard Yao-2
In reply to this post by Thomas Deutschmann


> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
>
>> On 2018-09-12 16:50, Rich Freeman wrote:
>> There is also the case where we want these warnings to block
>> installation, because the risk of there being a problem is too great.
>
> I really disagree with that. So many devs have already said multiple
> times in this thread that "-Werror" is only turning existing warnings
> into fatal errors but "-Werror" itself doesn't add any new checks and
> more often requires "-O3" to be useful.
The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.

> So let's turn this around: Please show us a *real* case within Gentoo
> where "-Werror" prevented a real problem which wouldn't otherwise being
> noticed. E.g. show us a package which was merged on user's system,
> replacing a working previous version of that package causing *real*
> problems which could have been prevented if package would have set
> "-Werror".
>
> Unless you can do that we don't really need to discuss this. Simply
> because everyone interested in "-Werror" *can* set that flag via CFLAGS,
> even just per package, whereas the majority, not interested in this,
> cannot do the same to filter "-Werror". Nobody advocating for "-Werror"
> replied to that fact yet.
>
>
> --
> Regards,
> Thomas Deutschmann / Gentoo Linux Developer
> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
>


Reply | Threaded
Open this post in threaded view
|

Re: acceptable alternatives to -Werror, was: Changing policy about -Werror

Richard Yao-2
In reply to this post by Chí-Thanh Christopher Nguyễn


> On Sep 12, 2018, at 8:23 PM, Chí-Thanh Christopher Nguyễn <[hidden email]> wrote:
>
> Rich Freeman schrieb:
>>> Requirements:
>>>
>>> * Do not fail to build/install when a warning is encountered
>> On a particularly critical package like a filesystem, wouldn't we want
>> to still fail to install when a warning is encountered?
>
> Installation will proceed, but the user will get a big fat warning that the sys-fs/zfs package is potentially broken.

The way that it works is that a user explicitly must enable USE=debug for -Werror to apply. The package itself’s use of -Werror in USE=debug does not prevent corruption issues so much as it detects them because the kernel code is built in userspace. sys-fs/zfs-kmod is what matters for this. USE=debug does not turn on -Werror there because we don’t inject it into the kernel build system. If such a bug is detected and a user proceeds to use the rebuilt kernel module, things could go poorly.

Anyway, I seem to have injected noise into the conversation by bringing this up because the discussion is whether -Werror by default should be allowed. I only commented because I felt that it should be an exception in the case of USE=debug or an explicit USE flag for Werror (e.g. USE=Werror).

>
>> I get that users might quit if packages don't install, but I'm not
>> sure that a filesystem corruption is going to make them any happier...
>
> If the user recognizes this as a critical package, then they can do the research before deciding on whether to use the package as is, attempt to downgrade, or wait until a fix is released.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>


Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Mike Pagano
In reply to this post by Ulrich Mueller-2


On 9/13/18 7:25 AM, Ulrich Mueller wrote:

>>>>>> On Wed, 12 Sep 2018, Mike  wrote:
>
>> Picking random email.
>
>> I would like to say I'm glad we can discuss our technical differences
>> like this with both sides expressing their opinion and reasoning.
>
>> I would hope in the future we start with this path and not with
>> disciplinary action or bugs requesting the removal of commit access.
>
>> We're showing here we can bring up our points without handing out "QA
>> strikes" or some other type of confrontational action.
>
> Sorry, but I am tired of that antagonising of the QA team.
>
> There hasn't been any bug about commit access removal. And not sure what
> you mean with "QA strike", but there also wasn't any direct QA action on
> the package that triggered the current discussion. After being CCed to a
> bug, the QA team has merely pointed out to the maintainer that the
> package is not in agreement with the current policy (as it is defined in
> the devmanual).
>
> IMHO this is the QA team's purpose. Or what would you expect us to do
> instead? Remain silent if asked by another developer to evaluate an
> issue? Then we could as well disband QA.
>
> Also note that there are several remedies if there is disagreement
> between a maintainer and QA, like asking QA for an exception, appealing
> to the council, or changing the policy in question.
>
> Ulrich
>
I'm sorry you feel I am antagonizing QA. I've never had a problem with
QA, personally.

And I apologize for writing that commit rights were requested to be
removed.  My mistake, bugzilla access rights were asked to be removed.

I actually thought I was complimenting our process. Seeing people
discuss their technical differences.

I'm not a fan of more and more and more regulation that I see.  Sorry if
you don't like that opinion.

And by "QA strike", I am referring to the policy that was posted and
then rescinded.

But, this is all off-topic of this thread.








signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Rich Freeman
On Thu, Sep 13, 2018 at 9:29 AM Mike <[hidden email]> wrote:
>
> And I apologize for writing that commit rights were requested to be
> removed.  My mistake, bugzilla access rights were asked to be removed.
>...
>
> I'm not a fan of more and more and more regulation that I see.  Sorry if
> you don't like that opinion.
>

What regulation?  No action was taken.

We can't exactly stop people from asking governance bodies to do
things.  At most we can say no when they ask.

Unless we want to make people ask if they can ask.  Now, that would be
regulation...  :)

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Mike Pagano


On 9/13/18 9:35 AM, Rich Freeman wrote:

> On Thu, Sep 13, 2018 at 9:29 AM Mike <[hidden email]> wrote:
>>
>> And I apologize for writing that commit rights were requested to be
>> removed.  My mistake, bugzilla access rights were asked to be removed.
>> ...
>>
>> I'm not a fan of more and more and more regulation that I see.  Sorry if
>> you don't like that opinion.
>>
>
> What regulation?  No action was taken.
>
> We can't exactly stop people from asking governance bodies to do
> things.  At most we can say no when they ask.
>
> Unless we want to make people ask if they can ask.  Now, that would be
> regulation...  :)
>
It was an attempt at a compliment of us working together.





signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Ulrich Mueller-2
>>>>> On Thu, 13 Sep 2018, Mike  wrote:

> On 9/13/18 9:35 AM, Rich Freeman wrote:
>> What regulation?  No action was taken.
>>
>> We can't exactly stop people from asking governance bodies to do
>> things.  At most we can say no when they ask.
>>
>> Unless we want to make people ask if they can ask.  Now, that would
>> be regulation...  :)

> It was an attempt at a compliment of us working together.

It just didn't come across like that (at least not to me).
Never mind then.

Ulrich

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Fabian Groffen-2
In reply to this post by Thomas Deutschmann
On 13-09-2018 00:55:45 +0200, Thomas Deutschmann wrote:
> Unless you can do that we don't really need to discuss this. Simply
> because everyone interested in "-Werror" *can* set that flag via CFLAGS,
> even just per package, whereas the majority, not interested in this,
> cannot do the same to filter "-Werror". Nobody advocating for "-Werror"
> replied to that fact yet.

Unfortunately adding -Werror to CFLAGS is not just possible.  Many
configure checks rely on the compiler just generating something,
ignoring warnings for various reasons.  If you add -Werror to your
CFLAGS you basically introduce breakage for some autoconf-based
packages.

What we really should be having is an easy way for post-configure CFLAGS
addition.  Just to support devs/users who insist on this for their
setups.

Fabian

--
Fabian Groffen
Gentoo on a different level

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Fabian Groffen-2
In reply to this post by Matt Turner-5
On 12-09-2018 17:46:03 -0700, Matt Turner wrote:

> On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman <[hidden email]> wrote:
> >
> > On Wed, Sep 12, 2018 at 7:52 PM Matt Turner <[hidden email]> wrote:
> > >
> > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman <[hidden email]> wrote:
> > > > Now, I could buy that -Werror turns NEW warnings into fatal errors,
> > > > due to the use of a newer toolchain, since upstream probably didn't
> > > > test with that toolchain and thus wouldn't have seen the warning.
> > >
> > > Yes, exactly. This is one of the major things people have said repeatedly.
> > >
> > > Werror makes moving gcc forward much more difficult.
> > >
> >
> > Sure, but wouldn't a block on newer versions of gcc cause similar headaches?
>
> Sure...? Who is suggesting that? I'm not sure where you're going with this.
>
> With new GCC comes new warnings, and harmless as the vast majority are
> they cause the build to break with Werror.
To illustrate harmless:
  warning: this statement may fall through [-Wimplicit-fallthrough=]
The warning message already has it in it that it's just a pure guess.


--
Fabian Groffen
Gentoo on a different level

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Alon Bar-Lev-2
On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen <[hidden email]> wrote:
>
> On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman <[hidden email]> wrote:
> > With new GCC comes new warnings, and harmless as the vast majority are
> > they cause the build to break with Werror.
>
> To illustrate harmless:
>   warning: this statement may fall through [-Wimplicit-fallthrough=]
> The warning message already has it in it that it's just a pure guess.

One that exposed a lot of unintentional fallthoughs which were fixed
when reporting to upstream.

Once again... we should discuss to leave -Werror when policy of
upstream to have no warnings and is maintaining that policy properly
while we at downstream may cooperate and avoid patching upstream but
discuss issues when found.

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Fabian Groffen-2
In reply to this post by Richard Yao-2
On 13-09-2018 07:36:09 -0400, Richard Yao wrote:

>
>
> > On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann <[hidden email]> wrote:
> >
> >> On 2018-09-12 16:50, Rich Freeman wrote:
> >> There is also the case where we want these warnings to block
> >> installation, because the risk of there being a problem is too great.
> >
> > I really disagree with that. So many devs have already said multiple
> > times in this thread that "-Werror" is only turning existing warnings
> > into fatal errors but "-Werror" itself doesn't add any new checks and
> > more often requires "-O3" to be useful.
> The way that compilers work is that the warnings are generated in the front end while the optimization level affects the backend. That means that -O3 has no effect on the code that does error generation. This remark about -O3 being needed to make -Werror useful is just plain wrong.
Huh?  -O3 enables more checks, which can generate more warnings.  -O3
isn't "needed", but if upstream is so interested in clean and correct
code, they should've fixed all warnings in the first place and thus
enabled all of them.  In fact, I expect every sane upstream to use "-O3
-Wall -Werror" in one of their automated builds.  Not that this catches
anything useful on x86{,_64} when there is for instance use of signed
and unsigned char types, so it isn't conclusive.

The whole point in here is that -Werror doesn't add much if you care.
The whole point why it is not desired in Gentoo is that users don't
necessarily are developers, or even interested in fixing warnings --
regardless whether they point to real problems or not.

If there are real problems in a package (exposed by a compiler or not)
then this should ideally stand out during ~arch testing, or even before
when the Gentoo maintainer examines the build (might even use -Werror
for his own purposes).  If such code ends up in stable arch we just made
a stabilisation mistake, or got royally messed up by upstream, depending
how you look at it.

Fabian

--
Fabian Groffen
Gentoo on a different level

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Fabian Groffen-2
In reply to this post by Rich Freeman
On 12-09-2018 20:09:54 -0400, Rich Freeman wrote:

> On Wed, Sep 12, 2018 at 7:32 PM Chí-Thanh Christopher Nguyễn
> <[hidden email]> wrote:
> >
> > Alon Bar-Lev schrieb:
> > > We
> > > are unique as permutations and architectures that are used by Gentoo
> > > users are so diverse that we find issues that nobody else finds.
> >
> > This needs to be highlighted more, as it is why suggestions that the
> > maintainer can simply put -Werror back on their own system are insufficient.
> >
>
> Wouldn't running into new runtime issues be exactly the sort of reason
> why we'd want to build with -Werror on packages where these issues are
> unacceptable?
Can you think of a way in which a new runtime issue would occur that
-Werror would have guarded?  And that issue would also get through
maintainer and ~arch testing?

Fabian

--
Fabian Groffen
Gentoo on a different level

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Fabian Groffen-2
In reply to this post by Alon Bar-Lev-2
On 13-09-2018 18:56:13 +0300, Alon Bar-Lev wrote:

> On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen <[hidden email]> wrote:
> >
> > On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> > > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman <[hidden email]> wrote:
> > > With new GCC comes new warnings, and harmless as the vast majority are
> > > they cause the build to break with Werror.
> >
> > To illustrate harmless:
> >   warning: this statement may fall through [-Wimplicit-fallthrough=]
> > The warning message already has it in it that it's just a pure guess.
>
> One that exposed a lot of unintentional fallthoughs which were fixed
> when reporting to upstream.
Sure that's why the warning is there.  But you ignore the point that the
same code compiled fine and ran fine for years without problems.

> Once again... we should discuss to leave -Werror when policy of
> upstream to have no warnings and is maintaining that policy properly
> while we at downstream may cooperate and avoid patching upstream but
> discuss issues when found.

On a developer's system, that would be nice.

For ordinary users on the other hand:
Leaving -Werror is leaving our users alone in the dark.  Don't do that.

--
Fabian Groffen
Gentoo on a different level

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Alon Bar-Lev-2
On Thu, Sep 13, 2018 at 7:20 PM Fabian Groffen <[hidden email]> wrote:
> > > To illustrate harmless:
> > >   warning: this statement may fall through [-Wimplicit-fallthrough=]
> > > The warning message already has it in it that it's just a pure guess.
> >
> > One that exposed a lot of unintentional fallthoughs which were fixed
> > when reporting to upstream.
>
> Sure that's why the warning is there.  But you ignore the point that the
> same code compiled fine and ran fine for years without problems.

The fact that something is compiling and running fine meaning there
are no issues (bugs) within code?
Seriously?
Even after no-warning with multiple compiler vendors, code coverage,
unit testing, test on various of architecture developer has access to,
static code analysis and running for years, bugs are there. Any method
to help detect suspicious code, even if it produces amount of false
positive, must be embraced of those who care about quality. New
toolchains, new scanners, new architectures all can help to improve
quality to make sure great service is provided to users.

In Gentoo language, all these issues should be detected for selected
packages by non-stable users, on architecture and permutations that
upstream do not have access to, and to help upstream to filter false
positives and find the positives ones. Even one case of funding real
issue is sufficient to justify the maintenance costs, once again for
selected packages in which upstream following strict quality policy
and downstream follows. Once policy is applied, the amount of noise is
very little, toolchain evolution is not as it was 10 years ago.

Regards,
Alon

Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Nikos Chantziaras-2
In reply to this post by Andrew Savchenko
On 09/09/2018 14:32, Andrew Savchenko wrote:

> My point is that in *most* cases -Werror indeed should be removed,
> because upstream rarely can keep up with all possible configure,
> *FLAGS, compiler versions and arch combinations. But! In some cases
> — especially for security oriented software — this flag may be
> pertain and may be kept at maintainer's discretion.
>
> The rationale is that -Werror usually points to dangerous
> situations like uninitialized variables, pointer type mismatch or
> implicit function declaration (and much more) which may lead to
> serious security implications.

Not sure if user feedback is welcome or not, but consider:

A piece of security oriented software gets an update (v2) that closes a
security hole in v1. User tries to update to v2, but the emerge fails
because of -Werror. User stays on v1 and thus remains vulnerable.

-Werror achieved the exact opposite of what the intent was.


Reply | Threaded
Open this post in threaded view
|

Re: Changing policy about -Werror

Sergei Trofimovich-6
In reply to this post by Alon Bar-Lev-2
On Tue, 11 Sep 2018 12:44:38 +0300
Alon Bar-Lev <[hidden email]> wrote:

I'm personally in favour of not allowing -Werror
to be in build system unconditionally.

Maintainer is free to implement --enable-werror any way
it's convenient to run on their own extended sanity checks
and optionally expose it to users. Be it USE flag or
EXTRA_ECONF option.

> I would like to suggest a modify our policy with the following
> exception clause: Package maintainer may decide to keep upstream
> -Werror as long as he is willing to resolve all issues resulting from
> -Werror as if it was a blocker bug.

Do you intend to keep -Werror for case when ebuild goes
stable as well?

If you do it then what is your workflow to fix breakages
appearing in stable packages caused by minor environment
changes like toolchain tweaks?

Add another round of stabilization on each arch team? It
sounds like your default assumption that code needs to be
changed in a semantically significant way: add annotations
that might not like some toolchains, remove unused code.

Or patch package in-place without bumping? None of options
sound optimal compared to dropping -Werror.

> The package maintainer decision may be based on the package state and
> the relationship with upstream, but basically, it is his decision as
> long as issues are fixed in timely manner, it is his overhead after
> all.

I agree that maintainer's will and upstream's will should be
respected and it's not something needs to be absolutely
enforced all the time.

Personally I disagree -Werror on end-user machine is worth
it (or cppcheck, or coverity round-trip run is worth running
on user's machine unconditionally).

Unused variable is a good example of typical benign warning:
it was there all the time, it's not a new bug and does not
warrant need for an immediate fix.

Toolchain just happend to get better at control flow graph
analysis. Fix can easily wait for next release and save
everyone's time.

Not every user is willing to create bugzilla account and figure
the path of reporting the breakage. Especially if there are
many breakages like that. Getting multiple various errors is
probable if one imagines -Werror to be commonly allowed.
This is user's overhead. Not just maintainer's.

Gentoo does not normally run tests on user's systems either.
Tests are arguably a lot more precise in pointing out real
problems in software.

> ARGUMENT: If a package compiled in the past using toolchain X then it
> must continue to do so with any future toolchain.
>
> I do not understand when "build" is the test for runtime

The argument was about "keep compiling". Runtime
behaviour is a separate issue and (in my opinion) is an
orthogonal topic.

On another note I occasionally like to build Gentoo with
clang's -Weverything (or equivalent set of gcc CFLAGS)
to get the idea if there is a good useful warning out there
to put into -Werror= list.

Explicit -Werror= list allows code not to regress. But even
that is prone to harmless infelicities in libc headers that
can't be easily fixed.

In case of opensc it just does not compile even if I pass -Wno-error:
    $ CC=clang CFLAGS="-O2 -Weverything -Wno-error" emerge -v1 opensc

I don't expect 'opensc' upstream to fix this use for me
and don't see it worth reporting to bugzilla.

But maybe I'm wrong?

--

  Sergei

123456