On 1/28/25 02:30, Torbjorn SVENSSON wrote:
On 2025-01-28 06:27, Jacob Bachmeyer wrote:
On 1/26/25 10:59, Torbjorn SVENSSON wrote:
[...]
On 2025-01-26 02:51, Jacob Bachmeyer wrote:
On 1/25/25 02:55, Torbjörn SVENSSON wrote:
[...]
As I understand, this is a shift in C dialect over the years if it
is a real issue. Originally, an empty argument list did not mean
"no arguments" but "unspecified arguments". To declare "no
arguments" you must explicitly write "func(void)" in C.
It was like this, but with C23, it's no longer the case.
Do I correctly understand that C23 also removed the K&R function
definition syntax? If so, testglue.c needs a lot more work than just
a few prototypes...
I'm not an expert on the specifications, but from what I can
understand of the Wikipedia article and the foot notes, I would say
that the K&R style cannot be used in C23.
The rest of testglue.c currently uses K&R style function definitions.
[...]
While I seem to recall that the C standard has always specified
exit(3) to take an "int" argument, it was also implicitly intended
for programs hosted on Unix and a freestanding board might not use
an exit code and simply halt or shut down when "exit()" is called.
I don't know if you are allowed to define "exit()" (without
arguments) and still be complaint with the C standard. If you are
not complaint with the C standard, then all bets are off. :)
For a function like exit() or _exit() that does not return, calling a
"func(void)" implementation as if it were "func(int)" should do no
harm. For most calling conventions, even doing that with a function
that *does* return should work; the exceptions are conventions where
the callee cleans up arguments passed on the stack.
I can add it to those functions, but in C23, there is no requirement
on that. Having nothing within the parenthesis is equal to writing
"void" in them.
The tentative plan at this point is to convert the file to "clean" K&R
if __STDC__ is not defined and "clean" ANSI (including C23) if __STDC__
is defined. The goal is to make the file work with *any* revision of C
and, ideally, *any* C compiler.
If you want the code to work more or less in the same grey zone as
before, I guess it could change to this:
#if __STDC_VERSION__ >= 202311L
extern void REAL_EXIT (int);
#else
extern void REAL_EXIT ();
#endif
I can send a V2 with this if you think that is better.
I will want a V2 in any case, but we may only need "#ifdef __STDC__"
instead of testing __STDC_VERSION__. Also, if adding explicit
prototypes, REAL_ABORT should explicitly take "(void)".
I don't think that checking __STDC__ is going to work:
$ diff -u0 <(echo | arm-none-eabi-gcc -dM -x c -E -o - -std=c17 - )
<(echo | arm-none-eabi-gcc -dM -x c -E -o - -std=c23 - )
--- /dev/fd/63 2025-01-28 09:04:36.687223645 +0000
+++ /dev/fd/62 2025-01-28 09:04:36.687223645 +0000
@@ -94,0 +95 @@
+#define __CHAR8_TYPE__ unsigned char
@@ -267 +268 @@
-#define __STDC_VERSION__ 201710L
+#define __STDC_VERSION__ 202311L
@@ -301,0 +303 @@
+#define __GCC_ATOMIC_CHAR8_T_LOCK_FREE 1
Both of those modes define __STDC__ because ANSI-style prototypes and
function definitions are *accepted* in both of those modes. In other
words, the changes *required* for C23 will be *accepted* all the way
back to C89, but will cause pre-ANSI compilers (if anyone is still using
one of those) to reject the module.
If they are guarded with "#ifdef __STDC__", then ANSI compilers will see
the prototypes while museum pieces will get the existing K&R style.
-- Jacob
