Strange return codes from old but good C program

[andrew clarke]

On Sun 2015-05-17 22:16:14 UTC+1000, Ian Smith (smithi at nimnet.asn.au) wrote:

> Hi,
> 
> I'm hoping someone can help me figure out the behaviour of a C program 
> executed repeatedly from a shell invoked by my freepascal program.
> 
> If anyone might care to download <http://www.moshier.net/de118i-2.zip> 
> (258071 bytes), unzip it and run 'make', the supplied makefile - a copy 
> of unixl.mak - should provide ssystem compiled for long double precision 
> maths, just as I wanted, with the following output from gcc from FreeBSD 
> 4.5 to 9.3-RELEASE.  (If clang has trouble on 10.X, please let me know)

That makefile defaults to gcc but allows you to build it with clang
(which spits out a bunch of warnings similar to gcc) using:

make -f unixl.mak CC=clang

> smithi at x200:~/de118i-2 % make
> gcc -O2 -c ssystem.c
> ssystem.c: In function 'resstate':
> ssystem.c:150: warning: incompatible implicit declaration of built-in 
>  function 'exit'
> ssystem.c: In function 'main':
> ssystem.c:180: warning: incompatible implicit declaration of built-in 
>  function 'malloc'

stdlib.h provides prototypes for exit() and malloc().

#include <stdlib.h>

> ssystem runs as well as ever, these warnings indicate no functional 
> issues, but they do highlight the author's poor (but unsurprising in 
> 1993, last updated 2004) choice of return codes both for real errors 
> (malloc, file I/O, and maths div by zero, bad args for trig functions 
> and such) which mostly exit(1) but some return 0 (!) - but when ending 
> successfully it returns _usually_ 22, but sometimes 11, or 10, both seen 
> so far, consistently when run with the same (different) parameters.

The code looks like ancient K&R C, which was a lot more relaxed with
syntax than modern ISO C compilers. Even by 1993, most C developers
had moved on from K&R.

> What's worse is I can't figure out where in ssystem.c any return code 
> might be set on completion of main(), which is just declared as:
> 
> main()
> {

This is fine in K&R, but the ISO C prototype for main() without arguments is:

int main(void);

> and ends with the last of its results and (accuracy) errors printf()s:
> 
>         ii += 6;
>         }
> #if FPESHOW	# floating point debug, here set to 0
> fperem();
> #endif
> } /* end of main program */
> 
> No variables called rc or anysuch .. so what sets these odd retcodes?

Normally you'd use a return statement, eg.

#include <stdio.h>             /* prototype for printf() */

int main(void)
{
    printf("Hello world.\n");  /* say hi */

    return 0;                  /* return zero to the OS */
}

I haven't checked the standard but it's plausible that the ISO C spec
allows a random return code if none is given, especially if no
prototype for main() is provided.

There may be tools around to convert K&R C code to ANSI/ISO C syntax,
rather than trying to do it by hand. The code may still need some
tweaking, though, eg. return 0 from main().

> I'd be grateful for any clue.  So far I assume any return code > 1 is 
> success, so far so good - but it doesn't feel deterministic enough :)
> 
> cheers, Ian  (please cc me, I'm subscribed to the digest)

Pretty sure I know you from FidoNet, years ago. Also Trev Roydhouse.
AUST_C_HERE, or another echo, maybe?

Regards
Andrew