Re: [PATCH] Correct function prototype for REAL_EXIT and REAL__EXIT

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