I wrote:
the idea that we might get many dozen such warnings on more-current
compilers is scarier, as that might well interfere with people's
ability to do development on, say, Windows. Could somebody check
whether MSVC for instance complains about format strings using z?
Or shall I just
On 2014-01-21 11:33:40 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-21 12:11:23 -0300, Alvaro Herrera wrote:
How difficult would it be to have expand_fmt_string deal with positional
modifiers? I don't think we need anything from it other than the %n$
On 2014-01-23 11:14:05 -0500, Tom Lane wrote:
OK, I'll take a look.
Thanks.
I am not too
happy about the runtime check as the test isn't all that meaningful, but
I couldn't think of anything better.
Yeah, it's problematic for cross-compiles, but no more so than configure's
existing
Andres Freund and...@2ndquadrant.com writes:
So, here's a patch adding %z support to port/snprintf.c including a
configure check to test whether we need to fall back.
OK, I'll take a look.
I am not too
happy about the runtime check as the test isn't all that meaningful, but
I couldn't think
Andres Freund and...@2ndquadrant.com writes:
I was wondering more about the nature of the runtime check than the fact
that it's a runtime check at all... E.g. snprintf.c simply skips over
unknown format characters and might not have been detected as faulty on
32bit platforms by that check.
On 2014-01-23 11:25:56 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I was wondering more about the nature of the runtime check than the fact
that it's a runtime check at all... E.g. snprintf.c simply skips over
unknown format characters and might not have been
Andres Freund and...@2ndquadrant.com writes:
snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
Actually, that coding isn't gonna work at all on platforms where size_t
isn't the same size as uint64. We could make it work by explicitly
casting the argument to whatever type we've decided to use as
On 2014-01-23 12:54:22 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
Actually, that coding isn't gonna work at all on platforms where size_t
isn't the same size as uint64. We could make it work by explicitly
casting
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-23 12:54:22 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
Actually, that coding isn't gonna work at all on platforms where size_t
isn't the same size as uint64. We
I wrote:
I checked on my HPUX box and find that what it prints for %zu is
zu, confirming my thought that it'd just abandon processing of the
%-sequence. (Interesting that it doesn't eat the z while doing
so, though.)
Further testing on that box shows that its ancient gcc (2.95.3) doesn't
I wrote:
the idea that we might get many dozen such warnings on more-current
compilers is scarier, as that might well interfere with people's
ability to do development on, say, Windows. Could somebody check
whether MSVC for instance complains about format strings using z?
Or shall I just
On 2014-01-23 17:21:11 -0500, Tom Lane wrote:
I wrote:
the idea that we might get many dozen such warnings on more-current
compilers is scarier, as that might well interfere with people's
ability to do development on, say, Windows. Could somebody check
whether MSVC for instance complains
Andres Freund and...@2ndquadrant.com writes:
Do we have a real policy against indenting nested preprocessor
statments? Just so I don't do those in future patches...
Indent 'em if you like, but pgindent will undo it. I ran the patch
through pgindent to see what it would do with those, and it
On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
I think this approach is fundamentally broken, because it can't reasonably
cope with any case more complicated than %zu or
Robert Haas escribió:
On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
Am I just too tired, or am I not getting how INT64_FORMAT currently
allows the arguments to be
On 2014-01-21 12:11:23 -0300, Alvaro Herrera wrote:
How difficult would it be to have expand_fmt_string deal with positional
modifiers? I don't think we need anything from it other than the %n$
notation, so perhaps it's not so problematic.
I don't think there's much reason to go there. I
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-21 12:11:23 -0300, Alvaro Herrera wrote:
How difficult would it be to have expand_fmt_string deal with positional
modifiers? I don't think we need anything from it other than the %n$
notation, so perhaps it's not so problematic.
I
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 17, 2014 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It's still the case that we need a policy against INT64_FORMAT in
translatable strings, though, because what's passed to the gettext
mechanism has to be a fixed string not something
On Jan21, 2014, at 18:56 , Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Perhaps we should jettison entirely the idea of using the operating
system's built-in sprintf and use one of our own that has all of the
nice widgets we need, like a format code that's
Florian Pflug f...@phlo.org writes:
On Jan21, 2014, at 18:56 , Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
it wouldn't play nice with GCC's desire to check format strings.
That last is a deal-breaker. It's not just whether gcc desires to check
this --- we
Andres Freund and...@2ndquadrant.com writes:
[ 0001-Add-support-for-printing-Size-arguments-to-elog-erep.patch ]
I think this approach is fundamentally broken, because it can't reasonably
cope with any case more complicated than %zu or %zd. While it's
arguable that we can get along without the
I wrote:
Meh. This isn't needed if we do what I suggest above, but in any case
I don't approve of removing the existing [U]INT64_FORMAT macros.
That breaks code that doesn't need to get broken, probably including
third-party modules.
After looking more closely I see you didn't actually
Hi,
On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
I think a better solution approach is to teach our src/port/snprintf.c
about the z flag, then extend configure's checking to force use of our
snprintf if the platform's version doesn't handle z. While it might be
objected that this creates a
On 2014-01-17 14:18:55 -0500, Tom Lane wrote:
I wrote:
Meh. This isn't needed if we do what I suggest above, but in any case
I don't approve of removing the existing [U]INT64_FORMAT macros.
That breaks code that doesn't need to get broken, probably including
third-party modules.
After
On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
[ 0001-Add-support-for-printing-Size-arguments-to-elog-erep.patch ]
I think this approach is fundamentally broken, because it can't reasonably
cope with any case more complicated than %zu or %zd.
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
I think a better solution approach is to teach our src/port/snprintf.c
about the z flag, then extend configure's checking to force use of our
snprintf if the platform's version doesn't handle z.
Hm. I
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
I think this approach is fundamentally broken, because it can't reasonably
cope with any case more complicated than %zu or %zd.
Am I just too tired, or am I not getting how INT64_FORMAT currently
I wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-01-17 13:50:08 -0500, Tom Lane wrote:
I think this approach is fundamentally broken, because it can't reasonably
cope with any case more complicated than %zu or %zd.
Am I just too tired, or am I not getting how INT64_FORMAT
On 2013-12-08 01:32:45 +0100, Andres Freund wrote:
On 2013-12-06 09:54:59 -0500, Peter Eisentraut wrote:
On 11/11/13, 12:01 PM, Tom Lane wrote:
I do recall Peter saying that the infrastructure knows how to
verify conversion specs in translated strings, so it would have to be
aware of
On Sun, 2013-12-08 at 01:32 +0100, Andres Freund wrote:
Patch 02 converts some elog/ereport() callers to using the z modifier,
some were wrong at least on 64 bit windows.
This is making the assumption that Size is the same as size_t. If we
are going to commit to that, we might as well
On 2013-12-08 11:43:46 -0500, Peter Eisentraut wrote:
On Sun, 2013-12-08 at 01:32 +0100, Andres Freund wrote:
Patch 02 converts some elog/ereport() callers to using the z modifier,
some were wrong at least on 64 bit windows.
This is making the assumption that Size is the same as
On 2013-12-06 09:54:59 -0500, Peter Eisentraut wrote:
On 11/11/13, 12:01 PM, Tom Lane wrote:
I do recall Peter saying that the infrastructure knows how to
verify conversion specs in translated strings, so it would have to be
aware of 'z' flags for this to work.
It just checks that the
On 11/11/13, 12:01 PM, Tom Lane wrote:
I do recall Peter saying that the infrastructure knows how to
verify conversion specs in translated strings, so it would have to be
aware of 'z' flags for this to work.
It just checks that the same conversion placeholders appear in the
translation. It
Hi,
I'd like to add support for the length modifier %z. Linux' manpages
describes it as:
z A following integer conversion corresponds to a size_t or ssize_t
argument.
Since gcc's printf format checks understand it, we can add support for
it similar to the way we added %m support.
Andres Freund and...@2ndquadrant.com writes:
I'd like to add support for the length modifier %z. Linux' manpages
describes it as:
z A following integer conversion corresponds to a size_t or ssize_t
argument.
Since gcc's printf format checks understand it, we can add support for
it
On 2013-11-11 11:18:22 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I'd like to add support for the length modifier %z. Linux' manpages
describes it as:
z A following integer conversion corresponds to a size_t or ssize_t
argument.
Since gcc's printf
On 2013-11-11 17:33:53 +0100, Andres Freund wrote:
On 2013-11-11 11:18:22 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I'd like to add support for the length modifier %z. Linux' manpages
describes it as:
z A following integer conversion corresponds to a
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-11 11:18:22 -0500, Tom Lane wrote:
I think you'll find that %m is a totally different animal, because it
doesn't involve consuming an argument position.
I was thinking of just replacing '%z' by '%l', '%ll' or '%' as needed
and not
Andres Freund and...@2ndquadrant.com writes:
gettext has support for it afaics, it's part of POSIX:
Really? [ pokes around at pubs.opengroup.org ] Hm, I don't see it
in Single Unix Spec v2 (1997), but it is there in POSIX issue 7 (2008).
Also, the POSIX page says it defers to the C standard,
On 2013-11-11 12:01:40 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
I'm less than sure that every version of gcc will recognize %z, either
...
It's been in recognized in 2.95 afaics, so I think we're good.
Hm. Strange. Has to have been backpatched to the ancient
On Mon, Nov 11, 2013 at 10:50 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
I'd like to add support for the length modifier %z. Linux' manpages
describes it as:
z A following integer conversion corresponds to a size_t or ssize_t
argument.
Since gcc's printf format checks
On 2013-11-11 12:18:46 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
gettext has support for it afaics, it's part of POSIX:
Really? [ pokes around at pubs.opengroup.org ] Hm, I don't see it
in Single Unix Spec v2 (1997), but it is there in POSIX issue 7 (2008).
On 2013-11-11 12:31:55 -0500, Robert Haas wrote:
On Mon, Nov 11, 2013 at 10:50 AM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
I'd like to add support for the length modifier %z. Linux' manpages
describes it as:
z A following integer conversion corresponds to a size_t or
Andres Freund and...@2ndquadrant.com writes:
On 2013-11-11 12:31:55 -0500, Robert Haas wrote:
I seem to recall that our %m support involves rewriting the error
string twice, which I think is actually kind of expensive if, for
example, you've got a loop around a PL/pgsql EXCEPTION block.
Yes,
44 matches
Mail list logo
