Thread: new compiler warnings
I recently started getting these: plpython.c: In function ‘PLy_output’: plpython.c:3468: warning: format not a string literal and no format arguments plpython.c: In function ‘PLy_elog’: plpython.c:3620: warning: format not a string literal and no format arguments plpython.c:3627: warning: format not a string literal and no format arguments Please fix. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas wrote: > I recently started getting these: > > plpython.c: In function ?PLy_output?: > plpython.c:3468: warning: format not a string literal and no format arguments > plpython.c: In function ?PLy_elog?: > plpython.c:3620: warning: format not a string literal and no format arguments > plpython.c:3627: warning: format not a string literal and no format arguments And I see this warning: compress_io.c:597: warning: passing arg 2 of `gzwrite' discards qualifiers from pointer target type -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote: > I recently started getting these: > > plpython.c: In function ‘PLy_output’: > plpython.c:3468: warning: format not a string literal and no format arguments > plpython.c: In function ‘PLy_elog’: > plpython.c:3620: warning: format not a string literal and no format arguments > plpython.c:3627: warning: format not a string literal and no format arguments > > Please fix. Which version of which compiler is showing this?
On Wed, Jan 26, 2011 at 4:20 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote: >> I recently started getting these: >> >> plpython.c: In function ‘PLy_output’: >> plpython.c:3468: warning: format not a string literal and no format arguments >> plpython.c: In function ‘PLy_elog’: >> plpython.c:3620: warning: format not a string literal and no format arguments >> plpython.c:3627: warning: format not a string literal and no format arguments >> >> Please fix. > > Which version of which compiler is showing this? I got it on gcc version 4.2.1 (Apple Inc. build 5664) I did not get it on Fedora 12, gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC). But I think I did get it on a recently-updated Fedora 13 box also, I can check if it's important. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Peter Eisentraut <peter_e@gmx.net> writes:
> On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote:
>> I recently started getting these:
>>
>> plpython.c: In function ‘PLy_output’:
>> plpython.c:3468: warning: format not a string literal and no format arguments
>> plpython.c: In function ‘PLy_elog’:
>> plpython.c:3620: warning: format not a string literal and no format arguments
>> plpython.c:3627: warning: format not a string literal and no format arguments
>>
>> Please fix.
> Which version of which compiler is showing this?
I've been seeing that for some time with gcc 2.95.3, so it's not exactly
a new issue. I've not seen it with modern versions, but I'm not sure
why not. What it's unhappy about is the "errhint(hint)" calls, which
I agree with it are dangerous on their face. Maybe you're 100% sure the
hint strings will never contain percent marks, but I'm not.
regards, tom lane
On Wed, Jan 26, 2011 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> On ons, 2011-01-26 at 06:33 -0500, Robert Haas wrote: >>> I recently started getting these: >>> >>> plpython.c: In function ‘PLy_output’: >>> plpython.c:3468: warning: format not a string literal and no format arguments >>> plpython.c: In function ‘PLy_elog’: >>> plpython.c:3620: warning: format not a string literal and no format arguments >>> plpython.c:3627: warning: format not a string literal and no format arguments >>> >>> Please fix. > >> Which version of which compiler is showing this? > > I've been seeing that for some time with gcc 2.95.3, so it's not exactly > a new issue. I've not seen it with modern versions, but I'm not sure > why not. What it's unhappy about is the "errhint(hint)" calls, which > I agree with it are dangerous on their face. Maybe you're 100% sure the > hint strings will never contain percent marks, but I'm not. More to the point, regardless of whether the warning is reasonable or not, there's tangible value in a warning-free build, which we have had on most of the systems I use until recently. My Ubuntu system is complaining about something unrelated and stupid, but I haven't taken time to look into what's required to fix it yet, and I don't think it's a new problem. (Why use Ubuntu instead of Red Hat, you ask? Because the last Fedora I put on there had bugs in the X driver that made it crash several times after every reboot, and occasionally at other times. The year of the Linux desktop is apparently NOT 2010, and I'm not holding my breath for 2011 either.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> But I think I did get it on a recently-updated Fedora 13 box also, I
> can check if it's important.
F-13 doesn't show it for me. I get the impression from these results
that maybe gcc versions >= about 4.4 have been tweaked to not show it
... which doesn't really seem like a step forward.
regards, tom lane
On ons, 2011-01-26 at 17:00 -0500, Robert Haas wrote: > More to the point, regardless of whether the warning is reasonable or > not, there's tangible value in a warning-free build, which we have had > on most of the systems I use until recently. I don't disagree that the warnings are valid. I'd just like to see them as well. It turns out you need -Wformat-security with newer GCC versions. We might want to add that to the standard options set. Anyway: Fixed.
Peter Eisentraut <peter_e@gmx.net> writes:
> It turns out you need -Wformat-security with newer GCC versions.
Ah-hah.
> We might want to add that to the standard options set.
+1. Probably this will require an extra configure test, but even so
it's well worthwhile.
regards, tom lane
On Wed, Jan 26, 2011 at 5:20 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On ons, 2011-01-26 at 17:00 -0500, Robert Haas wrote: >> More to the point, regardless of whether the warning is reasonable or >> not, there's tangible value in a warning-free build, which we have had >> on most of the systems I use until recently. > > I don't disagree that the warnings are valid. I'd just like to see them > as well. > > It turns out you need -Wformat-security with newer GCC versions. We > might want to add that to the standard options set. > > Anyway: Fixed. Thanks! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Bruce Momjian wrote:
> Robert Haas wrote:
> > I recently started getting these:
> >
> > plpython.c: In function ?PLy_output?:
> > plpython.c:3468: warning: format not a string literal and no format arguments
> > plpython.c: In function ?PLy_elog?:
> > plpython.c:3620: warning: format not a string literal and no format arguments
> > plpython.c:3627: warning: format not a string literal and no format arguments
>
> And I see this warning:
>
> compress_io.c:597: warning: passing arg 2 of `gzwrite' discards
> qualifiers from pointer target type
I can remove this warning by casting the pointer to (void *), rather
than (const void *) because that is what the prototype uses on my system
uses (libz.so.1.1.4):
ZEXTERN int ZEXPORT gzwrite OF((gzFile file,
const voidp buf, unsigned len));
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/src/bin/pg_dump/compress_io.c b/src/bin/pg_dump/compress_io.c
index fb280ab..a00bb54 100644
*** a/src/bin/pg_dump/compress_io.c
--- b/src/bin/pg_dump/compress_io.c
*************** cfwrite(const void *ptr, int size, cfp *
*** 594,600 ****
{
#ifdef HAVE_LIBZ
if (fp->compressedfp)
! return gzwrite(fp->compressedfp, ptr, size);
else
#endif
return fwrite(ptr, 1, size, fp->uncompressedfp);
--- 594,600 ----
{
#ifdef HAVE_LIBZ
if (fp->compressedfp)
! return gzwrite(fp->compressedfp, (void *)ptr, size);
else
#endif
return fwrite(ptr, 1, size, fp->uncompressedfp);
Bruce Momjian <bruce@momjian.us> writes:
>> And I see this warning:
>>
>> compress_io.c:597: warning: passing arg 2 of `gzwrite' discards
>> qualifiers from pointer target type
> I can remove this warning by casting the pointer to (void *), rather
> than (const void *) because that is what the prototype uses on my system
> uses (libz.so.1.1.4):
Casting away const manually isn't much of an improvement, and will more
than likely provoke warnings of its own on other compilers.
Aren't you overdue for a zlib update? I'm pretty sure there are known
security bugs in 1.1.4 (which dates from 2002). I see no such warning
with zlib 1.2.3, which itself isn't exactly wet behind the ears (2005).
regards, tom lane
Bruce Momjian wrote: > Bruce Momjian wrote: > > Robert Haas wrote: > > > I recently started getting these: > > > > > > plpython.c: In function ?PLy_output?: > > > plpython.c:3468: warning: format not a string literal and no format arguments > > > plpython.c: In function ?PLy_elog?: > > > plpython.c:3620: warning: format not a string literal and no format arguments > > > plpython.c:3627: warning: format not a string literal and no format arguments > > > > And I see this warning: > > > > compress_io.c:597: warning: passing arg 2 of `gzwrite' discards > > qualifiers from pointer target type > > I can remove this warning by casting the pointer to (void *), rather > than (const void *) because that is what the prototype uses on my system > uses (libz.so.1.1.4): > > ZEXTERN int ZEXPORT gzwrite OF((gzFile file, > const voidp buf, unsigned len)); I was just suggesting that others might also see this warning for older libs. You don't need to change it for me. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
> I can remove this warning by casting the pointer to (void *), rather
> than (const void *) because that is what the prototype uses on my system
> uses (libz.so.1.1.4):
> ZEXTERN int ZEXPORT gzwrite OF((gzFile file,
> const voidp buf, unsigned len));
BTW, I don't understand why that fixes it for you either. As you can
see, gzwrite *is* declared with const. The reason why you're getting a
warning is that zconf.h #define's const as nothing unless it thinks
you're on an ANSI compiler (and the difference between 1.1.4 and 1.2.3
is mostly that the former's test for ANSI-ness is brain dead). But if
you're compiling that #define then const or lack of it should mean
nothing to you.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > I can remove this warning by casting the pointer to (void *), rather > > than (const void *) because that is what the prototype uses on my system > > uses (libz.so.1.1.4): > > > ZEXTERN int ZEXPORT gzwrite OF((gzFile file, > > const voidp buf, unsigned len)); > > BTW, I don't understand why that fixes it for you either. As you can > see, gzwrite *is* declared with const. The reason why you're getting a > warning is that zconf.h #define's const as nothing unless it thinks > you're on an ANSI compiler (and the difference between 1.1.4 and 1.2.3 > is mostly that the former's test for ANSI-ness is brain dead). But if > you're compiling that #define then const or lack of it should mean > nothing to you. Let's wait and see if anyone else complains; I have adjusted things here. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +