This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
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

- 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:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]