Thread

  1. new compiler warnings

    Robert Haas <robertmhaas@gmail.com> — 2011-01-26T11:33:00Z

    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
    
    
  2. Re: new compiler warnings

    Bruce Momjian <bruce@momjian.us> — 2011-01-26T14:48:18Z

    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. +
    
    
  3. Re: new compiler warnings

    Peter Eisentraut <peter_e@gmx.net> — 2011-01-26T21:20:13Z

    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?
    
    
    
  4. Re: new compiler warnings

    Robert Haas <robertmhaas@gmail.com> — 2011-01-26T21:41:42Z

    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
    
    
  5. Re: new compiler warnings

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-01-26T21:50:24Z

    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
    
    
  6. Re: new compiler warnings

    Robert Haas <robertmhaas@gmail.com> — 2011-01-26T22:00:19Z

    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
    
    
  7. Re: new compiler warnings

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-01-26T22:15:54Z

    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
    
    
  8. Re: new compiler warnings

    Peter Eisentraut <peter_e@gmx.net> — 2011-01-26T22:20:47Z

    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.
    
    
    
    
  9. Re: new compiler warnings

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-01-26T22:34:10Z

    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
    
    
  10. Re: new compiler warnings

    Robert Haas <robertmhaas@gmail.com> — 2011-01-26T22:40:28Z

    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
    
    
  11. Re: new compiler warnings

    Bruce Momjian <bruce@momjian.us> — 2011-01-27T00:18:16Z

    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. +
    
  12. Re: new compiler warnings

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-01-27T00:58:52Z

    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
    
    
  13. Re: new compiler warnings

    Bruce Momjian <bruce@momjian.us> — 2011-01-27T01:02:59Z

    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. +
    
    
  14. Re: new compiler warnings

    Tom Lane <tgl@sss.pgh.pa.us> — 2011-01-27T01:08:31Z

    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
    
    
  15. Re: new compiler warnings

    Bruce Momjian <bruce@momjian.us> — 2011-01-27T01:16:53Z

    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. +