Message-Id: <200412312347.iBVNl60E010236@delorie.com> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Gary R. Van Sickle" To: Subject: RE: Bug: Missing va_end() in cygwin_internal() (OT) Date: Fri, 31 Dec 2004 17:46:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-IsSubscribed: yes Allow me to solve this one once and for all: > Dave Korn wrote: > > > Well, it's only gcc for which we can be absolutely sure it's a > > no-op. It might be important to other compilers for all we know. > > The last architecture I'm aware of where it would make a > difference was the old HP-3000 16-bit stack architecture > (obsolete since 1986), where the arguments were laid out in > the wrong order. (And it's way too old and obsolete to have a > gcc port, anyway :-/). > > Normally, args on such architectures are laid out such that > the first argument is at a known (negative) offset from the > stack frame base, and the others have increasing (negative) > offsets. The HP-3000 was *ss-backwards, in that the first > argument had the largest negative offset, with each > succeeding argument having a smaller negative offset, so you > had to go through incredible calisthenics to support varargs.. > > Max: keep looking for those nitpicky errors, though - the > next one may be significant.. > Standards is standards. They exist for the sole reason of short-circuiting issues like this from cropping up. In the current situation, you've got va_start()s in a number of places with no va_end()s. That's nonstandard, not nitpicky, case closed. So what does this nonstandardness result in? Sombody sees it, says "Hey, that's nonstandard and furthermore looks busted, what's going on?" Then one of the half-dozen or so people in the world that know all about the intricacies of varargs on all known compiler/hardware configurations present and future explains, "it actually ends up being a no-op mostly. Sometimes. So it isn't really needed. For the most part. Even though it is nonstandard and nobody but us six people have ever heard of this." Subsequently, in the future the code either: - Breaks because it is nonstandard. - Continues to work by accident, even though its nonstandard. In parallel with the code continuing to maybe work probably, the following will happen: - Months, perhaps years go by, and somebody else observes, "Hey, that's nonstandard and furthermore looks busted, what's going on?" - This catches Chris on a good day, and he flies into yet another apoplectic tantrum and bellows, "Why you insolent swine! How ignorant must one be to not fully understand that all the standards and C programming books are completely and utterly wrong?!?! Not to mention that this was discussed ad mortis back in ought-four; why, even the most cursory search of the voluminous archives should bring up the relevant sentence! You make me want to retch!" - Rinse - Repeat Nay, I come not to praise Caesar, but to bury him. To wit, here is the solution: - Put in the va_end()s. If they're no-ops, then whoop-de-do. If not, hey, we're covered there as well! That's known in academic circles as "win-win". Case closed. But of course the correct solution is an orphan, while failure has a thousand fathers. In that spirit, I present the following subsolutions: - Add a comment indicating why the expected and standard va_end() is not there. Comments are the things in between the "/*" and "*/" constructs. While this requires more work than simply doing things the right way and adding the va_end()s which end up being no-ops, and is therefore more likely to be implemented in that respect, the fact Nature abhors a comment makes this subsolution unliklely to ever be implemented. - Do nothing but watch the above-documented pattern unfold. My money's on this one. With yet another problem neatly solved, Gentle Reader, I shall bid you adeiu. Festivus for the rest of us, and a Happy New Year! -- Gary R. Van Sickle -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/