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
Message-ID: <04b601c4eeb3$c2cc6bb0$5308a8c0@robinson.cam.ac.uk>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: "Dave Korn" <dave DOT korn AT artimi DOT com>, <cygwin AT cygwin DOT com>
References: <NUTMEGGirL0vB1atCMm00000b3c AT NUTMEG DOT CAM DOT ARTIMI DOT COM>
Subject: Re: Bug: Missing va_end() in cygwin_internal()
Date: Thu, 30 Dec 2004 21:08:27 -0000
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Dave Korn wrote:
>> -----Original Message-----
>> From: cygwin-owner On Behalf Of Max Bowsher
>> Sent: 30 December 2004 19:05
>
>> Christopher Faylor wrote:
>>> On Thu, Dec 30, 2004 at 05:59:02PM -0000, Max Bowsher wrote:
>>>> There is no va_end() call in cygwin_internal().
>>>
>>> Or in functions from:
>>>
>>>  bsdlib.cc
>>>  fork.cc
>>>  pinfo.cc
>>>  strace.cc
>>>
>>> The lack doesn't seem to be causing much of a problem...
>>
>> Standards say va_end is required, but may be a noop in some
>> implementations.
>
>  99.9% of all known implementations.  I guess it might be an issue if one 
> day
> we want to port cygwin to run on Vax or somesuch....
>
>> I peered at the guts of gcc trying to work out whether that
>> was the case for cygwin, but got too lost to be sure.
>
>  AFAICS gcc supplies the mechanics to implement va_start and va_arg 
> however
> your architecture requires, but no way to define any functionality for 
> va_end
> at all.
>
>  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.

Thanks for the information!

Max.


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