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

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

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

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

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

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