Re: Incorrect usage of strtol, atoi for non-numeric junk inputs
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: michael@paquier.xyz, bharath.rupireddyforpostgres@gmail.com, pgsql-hackers@lists.postgresql.org
Date: 2021-07-14T15:02:47Z
Lists: pgsql-hackers
On 2021-Jul-14, Kyotaro Horiguchi wrote:
> > > pg_log_error("extra_float_digits must be in range -15..3");
> > > exit_nicely(1);
> >
> > Should we take this occasion to reduce the burden of translators and
> > reword that as "%s must be in range %d..%d"? That could be a separate
> > patch.
Yes, please, let's do it here.
> The first %s is not always an invariable symbol name so it could
> result in concatenating several phrases into one, like this.
>
> pg_log..("%s must be in range %s..%s", _("compression level"), "0", "9"))
>
> It is translatable at least into Japanese but I'm not sure about other
> languages.
No, this doesn't work. When the first word is something that is
not to be translated (a literal parameter name), let's use a %s (but of
course the values must be taken out of the phrase too). But when it is
a translatable phrase, it must be present a full phrase, no
substitution:
pg_log_error("%s must be in range %s..%s", "extra_float_digits", "-15", "3");
pg_log..("compression level must be in range %s..%s", "0", "9"))
I think the purity test is whether you want to use a _() around the
argument, then you have to include it into the original message.
Thanks
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"After a quick R of TFM, all I can say is HOLY CR** THAT IS COOL! PostgreSQL was
amazing when I first started using it at 7.2, and I'm continually astounded by
learning new features and techniques made available by the continuing work of
the development team."
Berend Tober, http://archives.postgresql.org/pgsql-hackers/2007-08/msg01009.php
Commits
-
Simplify matching pattern check in TAP tests of pg_receivewal
- 24ba1a87e405 15.0 landed
-
Skip trailing whitespaces when parsing integer options
- f7a9a3d4b24a 15.0 landed
-
Unify parsing logic for command-line integer options
- 6f164e6d1761 15.0 landed