Alvaro Herrera wrote:
> Magnus Hagander escribió:
>
>> For a change like
>> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480&r2=1.481
>>
>> Will it work to stick _(hintmsg) around it there?
>
> Assuming that there is a gettext_noop() call in the literal that's
Peter Eisentraut wrote:
-Wformat-security warns about
printf(var);
but not about
printf(var, a);
I don't understand that; the crash or exploit potential is pretty much the
same in both cases.
Not sure this is the reason, but in the first case any risk is trivially
avoided by usin
Alvaro Herrera writes:
> Magnus Hagander escribió:
>> For a change like
>> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480&r2=1.481
>>
>> Will it work to stick _(hintmsg) around it there?
> Assuming that there is a gettext_noop() call in the literal that's
>
Magnus Hagander escribió:
> For a change like
> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.480&r2=1.481
>
> Will it work to stick _(hintmsg) around it there?
Assuming that there is a gettext_noop() call in the literal that's
assigned to hintmsg, yes, it shou
Tom Lane wrote:
> Magnus, you wanna clean up the mess? And what patch does the "few more"
> comment refer back to?
>
> A workable solution that both silences the warning and preserves
> localizability is to follow a coding pattern like this:
>
> const char *mymsg = gettext_noop("Some text
On Sunday 18 January 2009 12:43:46 Grzegorz Jaskiewicz wrote:
> > -Wformat-security warns about
> >
> >printf(var);
> >
> > but not about
> >
> >printf(var, a);
> >
> > I don't understand that; the crash or exploit potential is pretty
> > much the
> > same in both cases.
>
> not at all. Fir
On Sunday 18 January 2009 21:15:28 Tom Lane wrote:
> BTW, does the gettext infrastructure make any checks to ensure that
> translators didn't bollix the format codes? It seems like that should
> be doable with just a SMOP, but I don't know if it's in there or not.
Yes, that is all taken care of.
Gregory Stark writes:
> Tom Lane writes:
>> The really nasty cases are like this:
>> const char *myfmt = gettext_noop("Some bleat about object \"%s\".");
>> ...
>> errmsg(myfmt, objectname)
> It makes sense to me: if you have arguments for the format string then
> presumably you've at some point
Tom Lane wrote:
> alan...@gmail.com writes:
>>> One thing to watch out for is that the intention may have been to allow
>>> the strings to be translated.
>
>> I'm not sure if that's the case. How does one find out?
>
> If the origin of the "variable" format is a constant or set of constants
> dec
Tom Lane 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 brea
alan...@gmail.com writes:
>> One thing to watch out for is that the intention may have been to allow
>> the strings to be translated.
> I'm not sure if that's the case. How does one find out?
If the origin of the "variable" format is a constant or set of constants
decorated with gettext_noop(), t
Grzegorz Jaskiewicz wrote:
On 2009-01-18, at 09:56, Peter Eisentraut wrote:
-Wformat-security warns about
printf(var);
but not about
printf(var, a);
I don't understand that; the crash or exploit potential is pretty much
the
same in both cases.
not at all. First case allows you to pas
On Jan 17, 2009 3:34pm, Peter Eisentraut wrote:
On Saturday 17 January 2009 11:44:07 Alan Li wrote:
> Attached are patches to fix the following compiler warnings that I see
when
> using gcc 4.3.2.
>
> MASTER warning:
> tablecmds.c: In function 'DropErrorMsgWrongType':
> tablecmds.c:601
On 2009-01-18, at 09:56, Peter Eisentraut wrote:
On Sunday 18 January 2009 08:28:51 Tom Lane wrote:
Yeah, the risk this is trying to guard against is variables
containing
"%" unexpectedly. Even if that's not possible, it requires some work
to verify and it's a bit fragile. I didn't look at
One thing to watch out for is that the intention may have been to allow
the strings to be translated.
regards, tom lane
I'm not sure if that's the case. How does one find out?
Alan
On Sunday 18 January 2009 08:28:51 Tom Lane wrote:
> Yeah, the risk this is trying to guard against is variables containing
> "%" unexpectedly. Even if that's not possible, it requires some work
> to verify and it's a bit fragile. I didn't look at the specific cases
> yet but in general I think t
Gregory Stark writes:
> There's an argument to be made that the code is easier to audit if you put the
> "%s" format string in explicitly too.
Yeah, the risk this is trying to guard against is variables containing
"%" unexpectedly. Even if that's not possible, it requires some work
to verify and
Peter Eisentraut writes:
> You apparently have your compiler configured with -Wformat-security. Our
> code
> doesn't do that. I think the cases the warning complains about are fine and
> the way the warning is designed is a bit bogus.
Hm, only a bit. You know, we've had precisely this bug
On Saturday 17 January 2009 11:44:07 Alan Li wrote:
> Attached are patches to fix the following compiler warnings that I see when
> using gcc 4.3.2.
>
> MASTER warning:
> tablecmds.c: In function 'DropErrorMsgWrongType':
> tablecmds.c:601: warning: format not a string literal and no format
> argume
Attached are patches to fix the following compiler warnings that I see when
using gcc 4.3.2.
MASTER warning:
tablecmds.c: In function 'DropErrorMsgWrongType':
tablecmds.c:601: warning: format not a string literal and no format
arguments
REL8_3_STABLE warnings:
utility.c: In function 'DropErrorMsg
20 matches
Mail list logo