Thread: Re: [HACKERS] PostgreSQL 6.5.2
wieck@debis.com
>[pgsql@hot] ~/devel/src/test/regress > ./checkresults
>====== int2 ======
>10c10
>< ERROR: pg_atoi: error reading "100000": Numerical result out of range
>---
>> ERROR: pg_atoi: error reading "100000": Math result not representable
>====== int4 ======
>10c10
>< ERROR: pg_atoi: error reading "1000000000000": Numerical result out of range
>---
>> ERROR: pg_atoi: error reading "1000000000000": Math result not representable
>[pgsql@hot] ~/devel/src/test/regress >
>
>
>
> Such a regression result while we're in the middle of feature
> development.
>
> I'm really impressed - if we only can keep it on this level!
>
I'm sure we could get rid of even those errors if we were to
incorporate some test like the following and then mangle the
expected results accordingly.
Trouble is I'm not sure how portable the code is:-
SPARCLinux compiles and gives "Math result not representable"
Solaris7 compiles and gives "Result too large"
Comments?
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
int main(void)
{ char *s = "10000000000000000000000000000000000000000000000000"; long l = 0; char
*badp= (char *) NULL;
errno = 0;
l = strtol(s, &badp, 10); if (errno) { printf("%s\n",strerror(errno));
exit(0); } else { printf("Error - No Error."); exit(1); }
}
> wieck@debis.com > >[pgsql@hot] ~/devel/src/test/regress > ./checkresults > >====== int2 ====== > >10c10 > >< ERROR: pg_atoi: error reading "100000": Numerical result out of range > >--- > >> ERROR: pg_atoi: error reading "100000": Math result not representable > >====== int4 ====== > >10c10 > >< ERROR: pg_atoi: error reading "1000000000000": Numerical result out of range > >--- > >> ERROR: pg_atoi: error reading "1000000000000": Math result not representable > >[pgsql@hot] ~/devel/src/test/regress > I am inclined to strip off error messages after the second : and the do the compare so: ERROR: pg_atoi: error reading "1000000000000": Math result not representa.. becomes: ERROR: pg_atoi: error reading "1000000000000": They we just have to make sure all calls to perror have a colon before them. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
> I'm sure we could get rid of even those errors if we were to
> incorporate some test like the following and then mangle the
> expected results accordingly.
I don't see much value in getting rid of the discrepancies in strerror()
messages unless you have some proposal for getting rid of platform-
specific float roundoff differences. On my machine, the diffs in the
float8 and geometry regress tests are *much* larger and much harder to
validate by eyeball than the piddling little diffs in int2 and int4.
(I suppose I should submit platform-specific expected files for HPUX,
but have never gotten round to it...)
However, if people like this approach, why not just print out
"strerror(ERANGE)" instead of fooling with strtol?
regards, tom lane
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> They we just have to make sure all calls to perror have a colon before
> them.
IIRC, perror is defined to supply the colon for you. But this approach
won't really work unless you want to guarantee that colons never appear
for any other reason in the regress outputs... horology, for one, is
going to have a problem with that...
It does seem that the majority of the platform-specific expected files
we have are for this one issue in int2/int4, so maybe Keith's idea of
substituting the correct error message as a localization string is not a
bad one. We already have all the mechanism for that.
regards, tom lane