Oddities in our pg_attribute_printf usage

Started by Tom Laneover 3 years ago1 messageshackers
Jump to latest
#1Tom Lane
tgl@sss.pgh.pa.us

Following my discovery of missed pg_attribute_printf coverage
in libpq_pipeline (cf2c7a736), I went looking to see if we'd
forgotten that anywhere else. The coverage seems to be solid
... except at the very root, where we have no such markers for
pg_vsnprintf, pg_vsprintf, pg_vfprintf, pg_vprintf.
I wonder if the option to write "0" for the second argument of
pg_attribute_printf didn't exist then, or we didn't know about it?

I'm not sure that adding those markers does all that much for
us, since (a) it's hard to see how the compiler could check
anything if it doesn't have the actual args list at hand,
and (b) these functions are likely never invoked with constant
format strings anyway. Nonetheless, it seems pretty silly that
we've faithfully labeled all the derivative printf-alikes but
not these fundamental ones.

I also noted that win32security.c thinks it can stick
pg_attribute_printf into a function definition, whereas all
the rest of our code thinks you have to append that marker
to a separate function declaration. Does that actually work
with Microsoft-platform compilers? Or more likely, is the
macro expanding to empty on every compiler we've used with
that code? Anyway, seems like we ought to make this fall
in line with the convention elsewhere.

So I end with the attached. Any objections?

regards, tom lane

Attachments:

fix-pg_attribute_printf-usage-1.patchtext/x-diff; charset=us-ascii; name=fix-pg_attribute_printf-usage-1.patchDownload+7-7