> > Um, I said it would change the ABI and I said as much in my
> > previous post.
>
> The ABI is only the smaller part of the problem; you'd be forcing
> people to change their source code, in a rather nonobvious way.
*sigh* This isn't worth it at this point. Having written several
logging interfaces recently, I thought it'd be a nice addition and
certainly one that I've appreciated as a consumer of my own APIs.
Regarding your point, however, it shouldn't require any changes:
func1(void *arg, char *msg) is written as:
func1(NULL, "foobar\n");
func1(NULL, "some static msg\n");
func1(NULL, "some error\n");
func1(NULL, "such and such is 100% full\n");
func2(void *arg, char *fmt, ...) is written as:
func2(NULL, "foobar\n");
func2(NULL, "some static msg\n");
func2(NULL, "some error\n");
func2(NULL, "blah happened at iteration %d in %s\n", i, "baz");
func2(NULL, "such and such is 100%% full\n");
Only in the last example there does it require any modification of the
source code if you want to be completely spec compliant, however, even
in the last case, you'd have to provide an argument to % in order for
it to break, at which point the compile would fail if -Wformat is used
(maybe even without -Wformat, but I always have it on):
fprintf(3):
% A `%' is written. No argument is converted. The complete con-
version specification is `%%'.
gcc(1):
-Wformat
Check calls to printf and scanf, etc., to make sure that the ar-
guments supplied have types appropriate to the format string
specified.
> > it is code compatible provided people aren't using any % escape
> > strings in their error messages (if there aren't any format
> > strings, there won't be any need to modify the program),
>
> And if there aren't any format strings, then we don't need to change
> the interface. I don't see your point at all. You cannot make use
> of the added functionality without breaking client applications.
See above. With libpq's version being bumped (is it?), apps will have
to be recompiled to make use of the new protocol, there shouldn't be
any extra mangling of app source code unless their strings contain
"%[\w]{1,2}", which is a relatively uncommon pattern to run across.
Like I said though, no biggie, just something that's a nice to have
for logging interfaces, so in the advent that we want all cases of
fprintf() to be removed from libpq (ex: PasswordFromFile()), the above
seems like an appropriate and low risk option. -sc
--
Sean Chittenden
