Re: How can Autoconf help with the transition to stricter compilation defaults?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Tue, Nov 15, 2022 at 2:08 PM Paul Eggert <eggert@xxxxxxxxxxx> wrote:
> On 2022-11-15 06:50, Jonathan Wakely wrote:
> > Could you clarify what you mean, with a concrete example? Surely as
> > long as errors are reported on stderr and the compiler exits with
> > non-zero status, that's an acceptable way to report errors?
> Not if the "error" is harmless as far as Autoconf is concerned, which is
> what led to this thread. The concrete example here is that Autoconf
> needs to check whether a function can be linked to (as opposed to
> checking the function's signature). Clang shouldn't get in the way.

What is harmless to autoconf is a critical flaw in another context.

> In lots of places the C standard says behavior is undefined, even though
> the behavior is fine on the current platform for the intended use. It's
> not just the example we're talking about; adding zero to a null pointer
> is another such example.
> In such cases it's OK for Clang to warn, but having Clang exit with
> nonzero status is overkill and counterproductive.

I don't know that this is particularly persuasive -- it effectively
boils down to another variant of "I want to rely on a specific
behavior for something that is UB". I don't think Clang can promise
that we're not going to turn more statically-known UB into errors.


[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux