Re: On non-Windows, hard depend on uselocale(3) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: On non-Windows, hard depend on uselocale(3)
Date
Msg-id 810814.1700261928@sss.pgh.pa.us
Whole thread Raw
In response to Re: On non-Windows, hard depend on uselocale(3)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: On non-Windows, hard depend on uselocale(3)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Change GUC hashtable to use simplehash?
Next
From: Melanie Plageman
Date:
Subject: Re: Emit fewer vacuum records by reaping removable tuples during pruning