From owner-freebsd-questions@FreeBSD.ORG Tue May 19 17:19:54 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 2B1D835A for ; Tue, 19 May 2015 17:19:54 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 7CEDB1A3E for ; Tue, 19 May 2015 17:19:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t4JHJS6E022238; Wed, 20 May 2015 03:19:29 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 20 May 2015 03:19:28 +1000 (EST) From: Ian Smith To: Brad Mettee cc: andrew clarke , Trev Roydhouse , freebsd-questions@freebsd.org, Polytropon Subject: Re: Strange return codes from old but good C program In-Reply-To: <5558CCC8.9030704@pchotshots.com> Message-ID: <20150520024236.N69409@sola.nimnet.asn.au> References: <20150517204503.V69409@sola.nimnet.asn.au> <20150517124223.GA82704@ozzmosis.com> <20150517232103.V69409@sola.nimnet.asn.au> <5558CCC8.9030704@pchotshots.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Tue, 19 May 2015 17:19:54 -0000 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 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