Please use -std=gnu89 for reference builds
fweimer-rh opened this issue · comments
The testsuite is mostly written in C89. By default, future compilers will not support C89-only language features that were in C99, leading to build failures.
diff --git a/test/ref/Makefile b/test/ref/Makefile
index abd3e9bc0..7c01bcfbb 100644
--- a/test/ref/Makefile
+++ b/test/ref/Makefile
@@ -40,7 +40,7 @@ OPTIONS = g O Os Osi Osir Osr Oi Oir Or
ISEQUAL = ..$S..$Stestwrk$Sisequal$(EXE)
CC = gcc
-CFLAGS = -O2 -Wall -W -Wextra -funsigned-char -fwrapv -fno-strict-overflow
+CFLAGS = -std=gnu89 -O2 -Wall -W -Wextra -funsigned-char -fwrapv -fno-strict-overflow
.PHONY: all clean
Related to:
I'd be curios to see what would actually break :)
Could you just make a PR for this?
@mrdudz Sorry, I can't create a fork of the repository because I do not have permission to publish some of your test cases. I'd appreciate if you could move this towards a conclusion without a PR.
I can't create a fork of the repository because I do not have permission to publish some of your test cases
??? please elaborate
Sorry, i don't understand. How is that a problem when you are making a fork on github in order to make a PR? shrug
He is working for a company that creates (and maybe sells) a Linux distribution. If he would fork the repository, he would distribute the code, but since he has a commercial background, this is not allowed according to the license cited.
It's a strict interpretation of the license but probably correct. Just because nothing serious would happen does not mean it is allowed.
The real problem is with cc65 which includes sources with a non-free license. The LCC license that covers some of the tests says:
Permission to use, copy, modify, and distribute this software for any
purpose, subject to the provisions described below, without fee is
hereby granted, provided that this entire notice is included in all
copies of any software that is or includes a copy or modification of
this software and in all copies of the supporting documentation for
such software.
Distributing LCC code as part of the cc65 sources without pointing to the LCC license is actually a license violation.
The tests contain other problematic code. I think it contains also GPLed code from SDCC without mentioning this anywhere but the sources.
BTW: SDCC is not better in this respect. Some time ago, it contained pieces of the cc65 runtime with the GPL attached to them. Looking now, references to cc65 have been removed, but it's still the code from cc65 and GPL licensed. Go figure.
A solution might be to move the tests into a separate repository that is not part of cc65. So cc65 could be clean zlib while the test repository (which is not actually necessary to use cc65) might have a mixture of licenses.
It's a strict interpretation of the license but probably correct.
I seriously doubt it (no fee involved). Would that be true... most of us would be violating various licenses all the time. I certainly would :)
BTW: SDCC is not better in this respect. Some time ago, it contained pieces of the cc65 runtime with the GPL attached to them. Looking now, references to cc65 have been removed, but it's still the code from cc65 and GPL licensed. Go figure.
Every single non trivial open source project i have worked with contained such "issues". It's only a matter of digging long enough, and you will find something someone copypasted from somewhere that he shouldnt have (and not seldomly without even knowing).
This reminds me of the drama about including cc65 in debian long ago :)
However - i think adding -std=gnu89 is actually not what we want, because cc65 isnt a c89 compiler and the testbench might use things not available in c89 - it should probably use the standard before the one that will totally drop the c89 things instead.
However - i think adding -std=gnu89 is actually not what we want
i agree. gnu89, as is totally obvious by its name, is a GNU extension and as such only recognized by compilers pretending to be GNUC compatible (i.e. gcc and clang). it would prevent compilation of cc65 with other compilers.
if this is added, it should only be added if the content of the CC variable ends with gcc or clang.
gnu89, as is totally obvious by its name, is a GNU extension and as such only recognized by compilers pretending to be GNUC compatible (i.e. gcc and clang). it would prevent compilation of cc65 with other compilers.
This is only about the testbench, not cc65 itself, though.
However - i think adding -std=gnu89 is actually not what we want, because cc65 isnt a c89 compiler and the testbench might use things not available in c89 - it should probably use the standard before the one that will totally drop the c89 things instead.
There wasn't a standard before C89/C90. Before standard C, there was K&R C, but cc65 seems to support the void keyword and function prototypes, so C89 looks a closer fit than K&R C (for which GCC does not implement a dialect mode anyway).
I used -std=gnu89 because the implied default for current is -std=gnu17, and I wanted to change as little as possible. I wouldn't be surprised if some of the tests failed to build with -std=c89 -pedantic-errors (the closest GCC can get to check for standard conformance).
There wasn't a standard before C89/C90. Before standard C, there was K&R C, but cc65 seems to support the void keyword and function prototypes, so C89 looks a closer fit than K&R C (for which GCC does not implement a dialect mode anyway).
Not sure what you are trying to say, but cc65 not only supports K&R and C89 (mostly), but also things from C99 and even some stuff from later standards (eg _Static_assert).
I used -std=gnu89 because the implied default for current is -std=gnu17, and I wanted to change as little as possible. I wouldn't be surprised if some of the tests failed to build with -std=c89 -pedantic-errors (the closest GCC can get to check for standard conformance).
It fails even with -std=gnu89 :) -std=c99 works, but that's only because no tests exist in that dir that would use stuff from later standards - hence the suggestion to use whatever the standard before the one removing the C89 things was (C17 i guess?)
I'm still under the impression there some 89 vs 99 confusion going on, sorry.
Our builds pass when building with gcc -std=gnu89. Note that C99 is the standard that removed the C89 bits (implicit function declarations, implicit int). Other things that GCC historically accepted weren't even in C89 to start with, but we'll keep supporting -std=gnu89 and -std=c89 without -pendantic-errors as some sort of legacy compatibility mode. Hopefully this makes it a little bit clearer?
Our builds pass when building with gcc -std=gnu89
??? I applied your patch locally, and the testbench doesn't pass anymore. (gcc 13.2.1)
Note that C99 is the standard that removed the C89 bits (implicit function declarations, implicit int).
that sounds wrong. C99 still allows implicit function declarations, empty prototypes, and defauls to int. it's only the upcoming C23 standard that forbids e.g. empty prototypes and maybe others.
Yes, C99 made it a requirement to issue a diagnostic about implicit int and the like, it'll still compile the code. The upcoming C23 will actually make those things an error.
Yes, C99 made it a requirement to issue a diagnostic about implicit int and the like, it'll still compile the code. The upcoming C23 will actually make those things an error.
Sorry, this is not accurate. C99 no longer discusses implicit int or implicit function declarations (except in the foreword, where it says that these features have been removed in this edition of the standard). Most cases of implicit int are simply syntax errors in the C99 grammar, and undeclared identifiers are treated as syntax errors, too, even if they look like function designators.
The C standard only talks about diagnostics, but leaves it up to the implementation how they are implemented (except for #error). Both warnings and errors are proper diagnostics according to the standard.
However, the compiler is still allowed to compile the code - and both clang and GCC do.
In any case, that patch breaks the testbench :)
I added -std=gnu17 now, which should do the trick for all practical purposes (see the comment in the Makefile)
I still wonder what this "Our builds pass when building with gcc -std=gnu89" refers to though :)
@mrdudz Sorry, this won't work. The C constructs you use are not part of C17, and GCC 14 will not accept them (fail compilation with a non-zero exit status) in C17 mode.
Does the failure you see involve test/ref/custom-reference.c? This test will indeed produce a non-zero exit status if compiled in C89 mode. It's not yet present in the downstream sources I use for testing. I suggest to use some other function (and not main) to produce the expected warning.
The C constructs you use are not part of C17, and GCC 14 will not accept them (fail compilation with a non-zero exit status) in C17 mode.
Are you saying that GCC 14 will enforce those things (ie make them errors instead of warnings) even for the older standards? That sounds like a crazy idea to me - tons of stuff will explode this way :) As i understood the upcoming change, this will apply to the C23 standard (only), and the problem is (only) that C23 will be the new default.
Does the failure you see involve test/ref/custom-reference.c?
indeed
This test will indeed produce a non-zero exit status if compiled in C89 mode. It's not yet present in the downstream sources I use for testing. I suggest to use some other function (and not main) to produce the expected warning.
As said before, that directory may contain tests that contain constructs of all kind of standards newer or older than C89 (it's just coincidence that it does not right now). If what you say is true, then the Makefile must be fixed and special casing added for individual tests (like the comment says).
I'll just leave it as it is now, and see what happens when the github runners update GCC - it's trivial to fix afterall
This breaks the ref tests for gcc versions older than 8.