Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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" To: Subject: RE: Bug: Missing va_end() in cygwin_internal() Date: Thu, 30 Dec 2004 19:33:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <03da01c4eea2$bcec1e40$5308a8c0@robinson.cam.ac.uk> Message-ID: X-OriginalArrivalTime: 30 Dec 2004 19:33:33.0703 (UTC) FILETIME=[73256970:01C4EEA6] > -----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.... 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/