Strange return codes from old but good C program

[William A. Mahaffey III]

On 05/17/15 07:48, andrew clarke wrote:
> 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.

I believe it's more than plausible, it's defined that unspecified return 
*will* return random garbage (more precisely, 'results are 
undefined').... not 100% certain, but about 99.9% confident. $0.02, no 
more, no less ....

<snip>

-- 

	William A. Mahaffey III

  ----------------------------------------------------------------------

	"The M1 Garand is without doubt the finest implement of war
	 ever devised by man."
                            -- Gen. George S. Patton Jr.