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

On 2025-01-28 06:27, Jacob Bachmeyer wrote:
> On 1/26/25 10:59, Torbjorn SVENSSON wrote:
>> Hi Jacub,
>>
>> Thanks for the review.
> 
> You are welcome.  A V2 will probably be requested (or I might just do it 
> and credit you for the initial patch) but whether to preserve backwards 
> compatibility or modernize the whole file is yet to be decided.
> 
>>
>> 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.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2510.pdf
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2841.htm

>> In C23, it's considered an error to call a function where the function 
>> prototype does not match the call site (only exception to this is the 
>> elipse AFAIK).
> 
> The ellipsis indicates varargs, so any number of arguments "match" the 
> ellipsis.  :-)

Indeed, I just wanted to make that part explicit. :)

>>> 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.

>> 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


Kind regards,
Torbjörn


>>> This also looks like you might actually know what testglue.c actually 
>>> does and how it is used.  Could you enlighten me on that or at least 
>>> point me to an example of something that uses it?  I am currently 
>>> reluctant to touch it because I do not know what changing it might 
>>> break.
>>
>> The testglue.c is used whenever you need to get status of a test case, 
>> but you cannot get the exit code directly by invoking the test 
>> application. A typical example is when you use a simulator or run 
>> tests on an embedded target though a GDB server.
>>
>> While running the gcc testsuite, you would specify that the testglue.c 
>> file is needed in your board definition using:
>>
>> set_board_info needs_status_wrapper  1
>>
>> This will build the testglue.c to an object file before the tests are 
>> started and then include the object file in the link phase of every 
>> executable.
>>
>> [...]
>>
>> The technique used to override exit, abort and main using the --wrap 
>> argument to the GNU linker.
>>
>> There is probably a lot more details that I've missed here to why it's 
>> implemented the way it is, but at least this gives you an idea of when 
>> and why it's may be needed.
> 
> Aha!  Now the code in that file makes sense to me.
> 
> 
> -- Jacob
> 
>