Happened to notice this:
postgres=# select numeric_send('NaN');
numeric_send
--------------------
\x00007f7ec0000000
(1 row)
7f7e obviously screams "accessing memory beyond the end of data", and
indeed this is so: init_var_from_num, when passed a NaN, accesses two
bytes after the input. This probably goes unnoticed because a NaN is 6
bytes including varlena header, so the next two bytes wouldn't cause a
segfault (and clients shouldn't care about the value since the NaN flag
is set), but it's still clearly wrong.
I can see two possible fixes: one to correct the assumptions in the
macros, the other to check for NaN before calling init_var_from_num in
numeric_send (all the other functions seem to do this check explicitly).
Which would be preferable?
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
