On 10/10/2023 18:30, Jason Merrill via Gcc wrote:
On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc <gcc@gcc.gnu.org>
wrote:
Are these code fragments valid C89 code?
int i1 = 1;
char *p1 = i;
char c;
char *p2 = &c;
int i2 = p2;
Or can we generate errors for them even with -std=gnu89?
(It will still be possible to override this with -fpermissive or
-Wno-int-conversion.)
Given that C89 code is unlikely to be actively maintained, I think we
should be permissive by default in that mode. People compiling with an old
-std flag are presumably doing it to keep old code compiling, and it seems
appropriate to respect that.
That is - unfortunately, IMHO - not true.
In particular, in the small-systems embedded development world (and that
is a /big/ use-case for C programming), there is still a lot done in
C89/C90. It is the dominant variety of C for things like RTOS's (such
as FreeRTOS and ThreadX), network stacks (like LWIP), microcontroller
manufacturers' SDK's and libraries, and so on. There are also still
some microcontrollers for which the main toolchains (not GCC, obviously)
do not have full C99 support, and there is a significant proportion of
embedded C programmers who write all their code in C90, even for new
projects. There is a "cult" within C coders who think "The C
Programming Language" is the "Bible", and have never learned anything
since then.
The biggest target device in this field is the 32-bit ARM Cortex-M
family, and the the most used compiler is gcc.
Taking numbers out of thin air, but not unrealistically I believe, there
are millions of devices manufactured every day running code compiled by
gcc -std=gnu89 or -std=c89 (or an equivalent).
Add to that the libraries on "big" systems that are written to C89/C90
standards. After all, that is the lowest common denominator of the
C/C++ world - with a bit of care, the code will be compatible with all
other C and C++ standards. It is not just of old code, though a great
deal of modern library code has roots back to pre-C99 days, but it is
also cross-platform code. It is only relatively recently that
Microsoft's development tools have had reasonable support for C99 - many
people writing code to work in both the *nix world and the Windows world
stick to C89/C90 if they want a clear standard (rather than "the subset
of C99 supported by the MSVC version they happen to have").
Now, pretty much all of that code could also be compiled with -std=c99
(or -std=gnu99). And in a great many cases, it /is/ compiled as C99.
But for those that want to be careful about their coding, and many do,
the natural choice here is "-std=c90 -pedantic-errors".
So IMHO (and as I am not a code contributor to GCC, my opinion really is
humble) it is better to be stricter than permissive, even in old
standards. It is particularly important for "-std=c89", while
"-std=gnu89" is naturally more permissive. (I have seen more than
enough terrible code in embedded programs - I don't want to make it
easier for them to write even worse code!)
I'm also (though less strongly) inclined to be permissive in C99 mode, and
only introduce the new strictness by default for C11/C17 modes.
I suspect (again with numbers taken from thin air) that the proportion
of C programmers or projects that actively choose C11 or C17 modes, as
distinct from using the compiler defaults, will be less than 1%. C99
(or gnu99) is the most commonly chosen standard for small-systems
embedded programming, combining C90 libraries, stacks, and RTOS's with
user code in C99. So again, my preference is towards stricter control,
not more permissive tools.
I am aware, however, that I personally am a lot fussier than most
programmers. I run gcc with lots of additional warnings and
-Wfatal-errors, and want ever-stricter tools. I don't think many people
would be happy with the choices /I/ would prefer for default compiler
flags!
I am merely a happy GCC user, not a contributor, much less anyone
involved in decision making. But I hope it is helpful to you to hear
other opinions here, especially about small-systems embedded
programming, at least in my own experience.
David
