Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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: "Dave Korn" <dave DOT korn AT artimi DOT com>
To: <cygwin AT cygwin DOT com>
Subject: RE: Bug: Missing va_end() in cygwin_internal()
Date: Thu, 30 Dec 2004 23:07:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <04b601c4eeb3$c2cc6bb0$5308a8c0@robinson.cam.ac.uk>
Message-ID: <NUTMEGtROUUHiC0iBRw00000b49@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 30 Dec 2004 23:07:20.0875 (UTC) FILETIME=[50BC87B0:01C4EEC4]

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

  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 7.15.1.3 it can change at
any time).

  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.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


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