Re: Fixes for compiler warnings

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: alanwli(at)gmail(dot)com, Magnus Hagander <magnus(at)hagander(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fixes for compiler warnings
Date: 2009-01-18 18:30:12
Message-ID: 87bpu4cvrf.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> The really nasty cases are like this:
>
> const char *myfmt = gettext_noop("Some bleat about object \"%s\".");
>
> ...
>
> errmsg(myfmt, objectname)
>
> where there really is no simple way to convince the compiler that you
> know what you're doing without breaking functionality. This is probably
> why -Wformat-security doesn't warn about the latter type of usage. It
> does kind of beg the question of why bother with that warning though ...

It makes sense to me: if you have arguments for the format string then
presumably you've at some point had to check that the format string has
escapes for those arguments.

The only danger in the coding style comes from the possibility that there are
escapes you didn't anticipate. It's a lot harder to expect specific non-zero
escapes and find something else than to just not think about it at all and
unknowingly depend on having no escapes.

And it would take willful ignorance to depend on having some specific set of
escapes in an unchecked string provided by an external data source, which is
where the worst danger lies.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2009-01-18 19:04:12 Re: Fixes for compiler warnings
Previous Message Tom Lane 2009-01-18 18:17:57 Re: Fixes for compiler warnings