[Top][All Lists]

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

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

From: Zack Weinberg
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Fri, 11 Nov 2022 21:56:47 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Nick Bowler <> writes:
> My gut feeling is that Autoconf should just determine the necessary
> options to get compatible behaviour out of these modern compilers, at
> least for the purpose of running configure tests.  For example, Autoconf
> should probably build the AC_CHECK_FUNC programs using gcc's
> -fno-builtin option

I fear this will cause more problems than it solves.  Messing with
compiler options inside a configure script has a track record of
clashing with “outer” build tools that expect to be able to dictate the

> It saddens me to see so much breakage happening in "modern C", a
> language that has (until now) a long history of new language features
> being carefully introduced to avoid these sort of problems.

I don’t exactly _disagree_ with this.  Quite a few of the compatibility-
breaking changes going into C2x (promoting ‘bool’ to a true keyword, for
instance, and changing the meaning of an empty argument list in a
function declaration) strike me as unnecessary churn.  However, the
specific set of changes that are under discussion right now—removal of
implicit function declarations, implicit int, and old-style function
definitions from the _default_ language accepted by C compilers—I’m very
much in favor of, because they make life significantly easier for people
writing _new_ code.  It’s not healthy for a language to always
prioritize old code over new code.

(Yes, you _can_ opt in to all three of those changes now, but you have
to type a bunch of -W options.  With my day job hat on, I am very much
looking forward to a day where ‘cc test.c’ errors out on implicit
function declarations, because then I won’t have to _explain_ implicit
function declarations, and why they are dangerous, to my students

>> p.s. GCC and Clang folks: As long as you’re changing the defaults out
>> from under people, can you please also remove the last few predefined
>> user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the
>> -std=gnuXX modes?
> Meh, even though these macros are a small thing I don't accept the
> "things are breaking anyway so let's break even more things" attitude.

Getting rid of these is another change that will make life easier for
people writing new code.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]