vsprintf() is defined in stdio.h like so:

	int vsprintf(char *, const char *, va_list);

so i suppose it's not unreasonable to expect the compiler to whine
about something like this:

	vsprintf(0,0,0);

except that in my case, stdio.h isn't included, there's no prototype
for vsprintf() in scope, and the thing compiling the code is simply
checking to see if the symbol exists in libc.  what i've found is
perplexing.

	% uname -srm ; gcc -v | & tail -1
	NetBSD 2.0G i386
	gcc version 3.3.3 (NetBSD nb3 20040520)
	% cat > foo.c <<EOF
	int main() {
	  vsprintf(0, 0, 0);
	  return (0);
	}
	EOF
	% cc -c foo.c
	% 

as compared to:

	% uname -srm ; gcc -v | & tail -1
	NetBSD 1.6ZL alpha
	gcc version 3.3.3 (NetBSD nb1 20040301)
	% cat > foo.c <<EOF
	int main() {
	  vsprintf(0, 0, 0);
	  return (0);
	}
	EOF
	% cc -c foo.c
	foo.c: In function `main':
	foo.c:2: error: incompatible type for argument 3 of `vsprintf'
	% 

fwiw, sparc64 with gcc 3.3.3 nb2 20040502 is also perfectly happy.

is this something that was "fixed" in the compiler between nb1 and
nb2?  does anyone feel like checking if there other other platforms
where gcc is unhappy?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."