This is the mail archive of the
mailing list for the Cygwin project.
RE: Bug: Missing va_end() in cygwin_internal()
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: <cygwin at cygwin dot com>
- Date: Thu, 30 Dec 2004 23:07:20 -0000
- Subject: RE: Bug: Missing va_end() in cygwin_internal()
> -----Original Message-----
> From: Max Bowsher
> Sent: 30 December 2004 21:08
> > Ah, found it. EXPAND_BUILTIN_VA_END was removed by
> > http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01368.html
> > I guess that VAX port will be ok after all, since it's
> being a supported
> > architecture for gcc means that it must not need va_end....
> I guess there's little point being picky in following the
> standard, given that evidence.
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. Given that nobody is
ever likely to care whether cygwin builds under any non-gcc compiler, there's
really no priority to adding the missing va_ends in, although it's conceivable
that some future version of gcc might bring back va_end and give it some real
But I wouldn't go omitting it in the general case, because your code is not
compliant with the C language spec if you don't use it properly, and there's no
reason to needlessly make your code unportable and at risk of changes to future
compiler behaviour (since it's undefined behaviour by 126.96.36.199 it can change at
It's the sort of thing I would tidy up just for neatness' sake if I was
working on a given file/function anyway, but wouldn't go out of my way to chase.
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html