Re: [HACKERS] snprintf causes regression

Bruce Momjian <[email protected]> Fri, 11 Mar 2005 12:44:19 -0500 (EST)
Newsgroups gmane.comp.db.postgresql.devel.win32,gmane.comp.db.postgresql.devel.general
Message-ID <[email protected]>
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[email protected]> writes:
> > >> I'm not sure that macros can have variable number of arguments on all
> > >> supported platforms. I've been burnt by this before.
> > 
> > > The actual patch is:
> > 	
> > > 	+ #ifdef __GNUC__
> > > 	+ #define vsnprintf(...)        pg_vsnprintf(__VA_ARGS__)
> > > 	+ #define snprintf(...) pg_snprintf(__VA_ARGS__)
> > > 	+ #define printf(...)           pg_printf(__VA_ARGS__)
> > > 	+ #else
> > > 	+ #define vsnprintf             pg_vsnprintf
> > > 	+ #define snprintf              pg_snprintf
> > > 	+ #define printf                pg_printf
> > > 	+ #endif
> > 
> > Uh, why bother with the different approach for gcc?
> 
> Because if we don't do that then the code above fails:
> 	
> 	extern int pg_snprintf(char *str, size_t count, const char *fmt,...)
> 	/* This extension allows gcc to check the format string */
> 	__attribute__((format(printf, 3, 4)));
> 
> The issue is that the "printf" here is interpreted specially by the
> compiler to mean "check arguments as printf".  If the preprocessor
> changes that, we get a failure.  The good news is that only gcc supports
> arg checking using __attribute__ and it also supports the __VA_ARGS__
> macros.  What I think we do lose is argument checking for non-gcc, but
> this seems as close as we can get.

I am adding a comment explaining why those macros are used.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  [email protected]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [email protected]