This is the mail archive of the
mailing list for the Cygwin project.
RE: Bug: Missing va_end() in cygwin_internal() (OT)
- From: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>
- To: <cygwin at cygwin dot com>
- Date: Fri, 31 Dec 2004 17:46:33 -0600
- Subject: RE: Bug: Missing va_end() in cygwin_internal() (OT)
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
- 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
Nay, I come not to praise Caesar, but to bury him. To wit, here is the
- 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
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