Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 May 2015 03:19:28 +1000 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        Brad Mettee <bmettee@pchotshots.com>
Cc:        andrew clarke <mail@ozzmosis.com>, Trev Roydhouse <trev@sentry.org>, freebsd-questions@freebsd.org, Polytropon <freebsd@edvax.de>
Subject:   Re: Strange return codes from old but good C program
Message-ID:  <20150520024236.N69409@sola.nimnet.asn.au>
In-Reply-To: <5558CCC8.9030704@pchotshots.com>
References:  <20150517204503.V69409@sola.nimnet.asn.au> <20150517124223.GA82704@ozzmosis.com> <20150517232103.V69409@sola.nimnet.asn.au> <5558CCC8.9030704@pchotshots.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, 17 May 2015 13:15:52 -0400, Brad Mettee wrote:
 > On 5/17/2015 12:43 PM, Ian Smith wrote:
 > > On Sun, 17 May 2015 22:42:24 +1000, andrew clarke wrote:
 > >   > On Sun 2015-05-17 22:16:14 UTC+1000, Ian Smith (smithi@nimnet.asn.au)

[..]

Firstly, thankyou to all who've contributed, on and off-list.  Now I 
have a pile of mail to fail to get through, but I did ask for it ..

 > I have a pretty good idea of why certain values are returned most, but not
 > all, of the time.
 > 
 > Specific code paths within any given application will regularly leave some
 > CPU registers loaded with specific values (the result of internal maths or
 > pointer usage). What you're seeing, on a normal basis, is the result of these
 > things occurring. The odd time that something else turns up is likely caused
 > by an OS operation that altered the register that's being used for the return
 > value.

Yes, or slightly different code paths, or things to count, whatever ..

If there's historical continuity I'd be betting on our old friend AL, 
especially after seeing Polytropon's Real Code examples.

 > My suggestion for this specific case would be to find any exit points from
 > the program that don't set a return value, and make sure they set it to
 > something that makes sense. In main, make sure it exits with a 0 (return 0;).
 > That way if you ever get a non-zero return value, you can be pretty sure that
 > the app didn't terminate normally. (Polytropon says pretty much the same
 > thing in his latest post)

Yes, and I need to patch a number of 'exit(0)' used for some real! 
errors, add int declarations to a number of functions and #include 
<stdlib.h> to 3 files, etc.  One post-extract patch should do the job.

 > As for the function definitions causing problems, why not go ahead and modify
 > them? You did say this code hasn't been touched in years, so it's not likely
 > your work will get overwritten with a new release.

Sure, and it's another step towards a port of now three pascal programs, 
for whom the output of ssystem is mere fodder :)

 > Hope this helps.

Sure has, thanks Brad and all,

Ian



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20150520024236.N69409>