Обсуждение: more C99 cleanup
I have been hunting down the last few pieces of code that made some obsolete claims about not being able to use C99 yet or needing to be compatible with pre-C99 or something like that. I found two obsolete comments and two places where we could now actually use the C99 functionality that the comment was anticipating. At least according to my grepping, all the remaining mentions of "C99" are now up to date and relevant.
Вложения
On Sat, Nov 22, 2025 at 2:50 AM Peter Eisentraut <peter@eisentraut.org> wrote: + * %z doesn't actually act differently from %Z on Windows. Probably obsolete too, at least according to: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?view=msvc-170
Peter Eisentraut <peter@eisentraut.org> writes:
> I have been hunting down the last few pieces of code that made some
> obsolete claims about not being able to use C99 yet or needing to be
> compatible with pre-C99 or something like that. I found two obsolete
> comments and two places where we could now actually use the C99
> functionality that the comment was anticipating.
Two comments:
* In 0001,
- * This implementation conforms to IEEE Std 1003.1 and GLIBC, in that the
- * case of hypot(inf,nan) results in INF, and not NAN.
I have a distinct recollection that this comment exists because we
found that some platforms had a hypot() that got that edge case wrong.
I don't object to proceeding on the assumption that they all conform
to spec by now, but please make sure there's at least one regression
test that will expose the problem if someplace doesn't. (A quick check
would be to hot-wire pg_hypot to do the wrong thing and see if any
existing test falls over. I think there is one, but let's verify.)
* In 0003, we can't be very sure what "isblank((unsigned char) c)"
will do with non-ASCII input data, except that it could very
easily do insane things with fragments of a multibyte character.
I recommend keeping pg_isblank but redefining it along the lines of
bool
pg_isblank(unsigned char c)
{
return (!IS_HIGHBIT_SET(c) && isblank(c));
}
to ensure the previous treatment of non-ASCII data.
(It could be made static in hba.c, perhaps)
regards, tom lane
I wrote:
> I have a distinct recollection that this comment exists because we
> found that some platforms had a hypot() that got that edge case wrong.
> I don't object to proceeding on the assumption that they all conform
> to spec by now, but please make sure there's at least one regression
> test that will expose the problem if someplace doesn't. (A quick check
> would be to hot-wire pg_hypot to do the wrong thing and see if any
> existing test falls over. I think there is one, but let's verify.)
Ah, there are several. It's not totally obvious perhaps where the
cause is. I'll attach the diffs just for the archives' sake.
regards, tom lane
diff -U3 /home/postgres/pgsql/src/test/regress/expected/geometry.out
/home/postgres/pgsql/src/test/regress/results/geometry.out
--- /home/postgres/pgsql/src/test/regress/expected/geometry.out 2025-09-16 11:41:22.033540812 -0400
+++ /home/postgres/pgsql/src/test/regress/results/geometry.out 2025-11-21 11:07:33.559382194 -0500
@@ -555,9 +555,9 @@
(1e+300,Infinity) | {0,-1,5} | Infinity | Infinity
(1e+300,Infinity) | {1,0,5} | NaN | NaN
(1e+300,Infinity) | {0,3,0} | Infinity | Infinity
- (1e+300,Infinity) | {1,-1,0} | Infinity | Infinity
- (1e+300,Infinity) | {-0.4,-1,-6} | Infinity | Infinity
- (1e+300,Infinity) | {-0.000184615384615,-1,15.3846153846} | Infinity | Infinity
+ (1e+300,Infinity) | {1,-1,0} | NaN | NaN
+ (1e+300,Infinity) | {-0.4,-1,-6} | NaN | NaN
+ (1e+300,Infinity) | {-0.000184615384615,-1,15.3846153846} | NaN | NaN
(1e+300,Infinity) | {3,NaN,5} | NaN | NaN
(1e+300,Infinity) | {NaN,NaN,NaN} | NaN | NaN
(1e+300,Infinity) | {0,-1,3} | Infinity | Infinity
@@ -653,7 +653,7 @@
(1e+300,Infinity) | [(11,22),(33,44)] | Infinity | Infinity
(1e+300,Infinity) | [(-10,2),(-10,3)] | Infinity | Infinity
(1e+300,Infinity) | [(0,-20),(30,-20)] | Infinity | Infinity
- (1e+300,Infinity) | [(NaN,1),(NaN,90)] | Infinity | Infinity
+ (1e+300,Infinity) | [(NaN,1),(NaN,90)] | NaN | NaN
(Infinity,1e+300) | [(1,2),(3,4)] | Infinity | Infinity
(Infinity,1e+300) | [(0,0),(6,6)] | Infinity | Infinity
(Infinity,1e+300) | [(10,-10),(-3,-4)] | Infinity | Infinity
@@ -1070,9 +1070,9 @@
(1e+300,Infinity) | {0,-1,5} | (1e+300,5)
(1e+300,Infinity) | {1,0,5} |
(1e+300,Infinity) | {0,3,0} | (1e+300,0)
- (1e+300,Infinity) | {1,-1,0} | (Infinity,NaN)
- (1e+300,Infinity) | {-0.4,-1,-6} | (-Infinity,NaN)
- (1e+300,Infinity) | {-0.000184615384615,-1,15.3846153846} | (-Infinity,NaN)
+ (1e+300,Infinity) | {1,-1,0} |
+ (1e+300,Infinity) | {-0.4,-1,-6} |
+ (1e+300,Infinity) | {-0.000184615384615,-1,15.3846153846} |
(1e+300,Infinity) | {3,NaN,5} |
(1e+300,Infinity) | {NaN,NaN,NaN} |
(1e+300,Infinity) | {0,-1,3} | (1e+300,3)
@@ -1168,7 +1168,7 @@
(1e+300,Infinity) | [(11,22),(33,44)] | (33,44)
(1e+300,Infinity) | [(-10,2),(-10,3)] | (-10,3)
(1e+300,Infinity) | [(0,-20),(30,-20)] | (30,-20)
- (1e+300,Infinity) | [(NaN,1),(NaN,90)] | (NaN,90)
+ (1e+300,Infinity) | [(NaN,1),(NaN,90)] |
(Infinity,1e+300) | [(1,2),(3,4)] | (3,4)
(Infinity,1e+300) | [(0,0),(6,6)] | (6,6)
(Infinity,1e+300) | [(10,-10),(-3,-4)] | (-3,-4)
On 21.11.25 15:03, Thomas Munro wrote: > On Sat, Nov 22, 2025 at 2:50 AM Peter Eisentraut <peter@eisentraut.org> wrote: > + * %z doesn't actually act differently from %Z on Windows. > > Probably obsolete too, at least according to: > > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?view=msvc-170 Right, we could got back to using %z on all platforms, as originally attempted by commit ad5d46a4494.
On 21.11.25 17:10, Tom Lane wrote: > I wrote: >> I have a distinct recollection that this comment exists because we >> found that some platforms had a hypot() that got that edge case wrong. >> I don't object to proceeding on the assumption that they all conform >> to spec by now, but please make sure there's at least one regression >> test that will expose the problem if someplace doesn't. (A quick check >> would be to hot-wire pg_hypot to do the wrong thing and see if any >> existing test falls over. I think there is one, but let's verify.) > > Ah, there are several. It's not totally obvious perhaps where the > cause is. I'll attach the diffs just for the archives' sake. For clarification, does what you are showing mean that the regression tests have enough coverage of the hypot() edge cases?
Peter Eisentraut <peter@eisentraut.org> writes:
> On 21.11.25 17:10, Tom Lane wrote:
>> Ah, there are several. It's not totally obvious perhaps where the
>> cause is. I'll attach the diffs just for the archives' sake.
> For clarification, does what you are showing mean that the regression
> tests have enough coverage of the hypot() edge cases?
We are definitely covering it. It's just that the present tests
fail in a way that wouldn't scream "hypot is broken" to some
future hacker dealing with such a failure. Not sure if that's
worth worrying about; but I'd lean to not worrying unless you
commit and we see such failures in the buildfarm.
regards, tom lane