strange result from contrib/seg regression on windows
I am seeing this (among other things) when running the seg contrib
module regression:
***************
*** 418,425 ****
ERROR: bad seg representation
DETAIL: syntax error at or near "e"
SELECT '1e700'::seg AS seg;
! ERROR: syntax error
! DETAIL: numeric value 1e700 unrepresentable
--
-- testing the operators
--
--- 418,428 ----
ERROR: bad seg representation
DETAIL: syntax error at or near "e"
SELECT '1e700'::seg AS seg;
! seg
! -----
! 1
! (1 row)
!
--
-- testing the operators
--Does anyone have a clue why? Can it be fixed? (I'll keep digging, but I
thought someone might be able to say immediately what it is.)
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Does anyone have a clue why?
Evidently your sscanf isn't setting errno for overflow --- look at
seg_atof() in segparse.y.
This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buffer that it
doesn't even need :-( I'd recommend ripping the whole thing out and
replacing with a call to float4in.
regards, tom lane
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Does anyone have a clue why?
Evidently your sscanf isn't setting errno for overflow --- look at
seg_atof() in segparse.y.This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buffer that it
doesn't even need :-( I'd recommend ripping the whole thing out and
replacing with a call to float4in.
Yeah. If anyone can do this quickly I'd be grateful. Otherwise it will
probably be a few days before I get it done.
Alternatively, could we not just use strtof instead of sscanf?
cheers
andrew
Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
Does anyone have a clue why?
Evidently your sscanf isn't setting errno for overflow --- look at
seg_atof() in segparse.y.This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buffer that it
doesn't even need :-( I'd recommend ripping the whole thing out and
replacing with a call to float4in.
Patch and alternative regression result file attached (Thanks to Tom for
an assist).
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
This code shows several other signs of severe brain death, actually,
like leaking 256 bytes on each call for an error message buffer that it
doesn't even need :-( I'd recommend ripping the whole thing out and
replacing with a call to float4in.Patch and alternative regression result file attached (Thanks to Tom for
an assist).
Applied.
regards, tom lane