From owner-freebsd-questions@FreeBSD.ORG Sun May 17 14:16:52 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D97C3A39 for ; Sun, 17 May 2015 14:16:51 +0000 (UTC) Received: from fly.hiwaay.net (fly.hiwaay.net [216.180.54.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4798147B for ; Sun, 17 May 2015 14:16:51 +0000 (UTC) Received: from kabini1.local (rbn1-216-180-19-53.adsl.hiwaay.net [216.180.19.53]) (authenticated bits=0) by fly.hiwaay.net (8.13.8/8.13.8/fly) with ESMTP id t4HEGmeK010518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 17 May 2015 09:16:49 -0500 Message-ID: <5558A2D0.8080207@hiwaay.net> Date: Sun, 17 May 2015 09:23:03 -0453 From: "William A. Mahaffey III" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 CC: freebsd-questions@freebsd.org Subject: Re: Strange return codes from old but good C program References: <20150517204503.V69409@sola.nimnet.asn.au> <20150517124223.GA82704@ozzmosis.com> In-Reply-To: <20150517124223.GA82704@ozzmosis.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 14:16:52 -0000 On 05/17/15 07:48, andrew clarke wrote: > On Sun 2015-05-17 22:16:14 UTC+1000, Ian Smith (smithi@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 >> (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@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 > >> 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 /* 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 .... -- William A. Mahaffey III ---------------------------------------------------------------------- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr.