mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-15 08:20:16 +08:00
a75a418d07
The restore() function assumed that the result of sprintf() with %e format would necessarily contain an 'e', which is false: what if the supplied number is an infinity or NaN? If that did happen, we'd get a null-pointer-dereference core dump. The case appears impossible currently, because seg_in() does not accept such values, and there are no seg-creating functions that would create one. But it seems unwise to rely on it never happening in future. Quite aside from that, the code was pretty ugly: it relied on modifying a static format string when it could use a "*" precision argument, and it used strtok() entirely gratuitously, and it stripped off trailing spaces by hand instead of just not asking for them to begin with. Coverity noticed the potential null pointer dereference (though I wonder why it didn't complain years ago, since this code is ancient). Since this is just code cleanup and forestalling a hypothetical future bug, there seems no need for back-patching. |
||
---|---|---|
.. | ||
data | ||
expected | ||
sql | ||
.gitignore | ||
Makefile | ||
seg--1.0.sql | ||
seg--unpackaged--1.0.sql | ||
seg-validate.pl | ||
seg.c | ||
seg.control | ||
segdata.h | ||
segparse.y | ||
segscan.l | ||
sort-segments.pl |