On 1/26/25 17:31, Rob Savoye wrote:
On Sat, Jan 25, 2025 at 07:51:44PM -0600, Jacob Bachmeyer wrote:

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.
   As the author of testglue.c, it was designed for ROM debug monitors
for testing libgloss and newlib on bare metal hardware. The debug
monitors weren't real operating systems, just something to download S
records or other formats to load the program and execute it. Exit
had to exist so code would link, and also to drop you back to the
debug monitor prompt.

   I think the C language has evolved since the early 90s when I wrote
that file. :-)

I see.  Between both responses explaining how that file is used, I now understand what it does and have a fairly good idea how to proceed here except for one question:

Does testglue.c still need to compile under pre-ANSI compilers?

I am initially inclined to keep that feature just on the general principle of preserving backwards compatibility.  I think we can maintain both by using "#ifdef __STDC__" to select ANSI-style and keep the K&R-style definitions away from C23 compilers.

... Wait a minute ... will a K&R compiler accept "extern void exit (int);" (which is visible unless WRAP_M68K_AOUT is defined) or has testglue.c been ANSI-only for a long time already and no one seems to have noticed?


Also, while we are here, since you (Rob) are the author of that file, could you add a full copyright/license notice (with the proper copyright years) to it?

I suggest LGPL3+ since its entrypoint interfaces are actually defined by the C standard and it is intended for use with code external to the framework.

In contrast, dejagnu.h is GPL because its interfaces are specific to DejaGnu (and the unit test protocol is documented---if people want to unit test their nonfree programs with DejaGnu, they can write their own unit test protocol implementations for those programs).


-- Jacob



Reply via email to