🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #3138

Re: <varargs.h> vs. function prototypes

#3138
From: Mark Hall
Date: Fri, 14 Jun 1991 17:51
69 lines
3002 bytes
In article <25353@oolong.la.locus.com> scotte@locus.com (Scott D. Eberline) writes:
>For software that may potentially be ported to platforms not yet
>ANSI-compliant, some functions taking variable arguments are
>defined using <varargs.h> instead of <stdarg.h>.  I would like
>to declare full prototypes for these to avoid compiler warnings
>about missing prototypes.  In the module in which these functions
>are defined, this doesn't seem to be possible:

OK, so you want your code to work with ANSI and non-ansi compilers.
Why not accomodate both in your source.  That's what the predefined
__STDC__ macro is for.

Declarations:
	#ifdef __STDC__
	void foo(char *format, ...);
	#else
	void foo();
	#endif

Definitions:

	#ifdef __STDC__
	void foo(char *format, ...)
	#else
	void foo(format, va_alist) char *format; va_dcl
	#endif
	{
		va_list ap;
		#ifdef __STDC__
			va_start(ap,format);
		#else
			va_start(ap);
		#endif
		
		[ ... rest of stuff the same ... ]
	}

>I'm a bit resigned to having missing prototype warnings for the module
>that contains the function definitions.  I'd still like to have
>prototypes in all the other modules, and the ellipsis notation
>seems to be the only way to do this.

It's nice to have a compiler which requires having prototypes if you
want them.  Of course, this isn't required by ANSI.

>How dangerous is it to call functions declared externally using the
>ellipsis notation, but defined using va_dcl?  

Very.  If a stdarg prototype is visible at a call site, it allows the
compiler to generate a different calling sequence.  For example, if a
compiler normally passes arguments in registers, it may choose to just
load them on the data stack instead when it sees a stdarg call site
(an optimization; otherwise it would just have to store down the 
registers on function entry).  Since it can depend on the definition of
the function to also have the stdarg notation, it will know how to
"pick up" the arguements in the function body.

>May a conforming implement-
>ation assume that functions with ellipsis prototypes use <stdarg.h>-style
>arguments and not <varargs.h>-style?

Well, it may assume that an ellipsis prototype was visible at every call
site of "foo" if "foo" is defined using the ellipsis notation.

>-- 
>Scott D. Eberline			scotte@locus.com  or  lcc!scotte

-Mark Hall (smart mailer): markhall@pyrps5.pyramid.com
	   (uucp paths): {uunet|ames|decwrl|sun|seismo}!pyramid!markhall
Technical Details
Message-ID: <159364@pyramid.pyramid.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!pyramid!pyrps5.pyramid.com!markhall
References: <25353@oolong.la.locus.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!pyramid!pyrps5.pyramid.com!markhall
From: markhall@pyrps5.pyramid.com (Mark Hall)
Newsgroups: comp.std.c
Subject: Re: <varargs.h> vs. function prototypes
Message-ID: <159364@pyramid.pyramid.com>
Date: 14 Jun 91 17:51:43 GMT
References: <25353@oolong.la.locus.com>
Sender: news@pyramid.pyramid.com
Distribution: na
Organization: Pyramid Technology Corporation, Mountain View
Lines: 69