I wrote:
> I've not reviewed this closely, but I did try it on mamba's host.
> It compiles and passes regression testing, but I see two warnings:
> common.c: In function 'PGTYPESsprintf':
> common.c:120:2: warning: function 'PGTYPESsprintf' might be a candidate for 'gnu_printf' format attribute
[-Wsuggest-attribute=format]
> 120 | return vsprintf_l(str, PGTYPESclocale, format, args);
> | ^~~~~~
> common.c: In function 'PGTYPESsnprintf':
> common.c:136:2: warning: function 'PGTYPESsnprintf' might be a candidate for 'gnu_printf' format attribute
[-Wsuggest-attribute=format]
> 136 | return vsnprintf_l(str, size, PGTYPESclocale, format, args);
> | ^~~~~~
> I think this is telling us about an actual problem: these new
> functions are based on libc's printf not what we have in snprintf.c,
> and therefore we really shouldn't be assuming that they will support
> any format specs beyond what POSIX requires for printf.
Wait, I just realized that there's more to this. ecpglib *does*
rely on our snprintf.c functions:
$ nm --ext --undef src/interfaces/ecpg/ecpglib/*.o | grep printf
U pg_snprintf
U pg_fprintf
U pg_snprintf
U pg_printf
U pg_snprintf
U pg_sprintf
U pg_fprintf
U pg_snprintf
U pg_vfprintf
U pg_snprintf
U pg_sprintf
U pg_sprintf
We are getting these warnings because vsprintf_l and
vsnprintf_l don't have snprintf.c implementations, so the
compiler sees the attributes attached to them by stdio.h.
This raises the question of whether changing snprintf.c
could be part of the solution. I'm not sure that we want
to try to emulate vs[n]printf_l directly, but perhaps there's
another way?
In any case, my concern about ecpg_log() is misplaced.
That is really using pg_vfprintf, so it's correctly marked.
regards, tom lane
