From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | Dave Cramer <dave(at)fastcrypt(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: FW: [JDBC] BIGINT vs Java's long |
Date: | 2001-08-07 19:44:03 |
Message-ID: | 11890.997213443@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> I don't think my patch against recent sources would apply cleanly to
> older ones, and I didn't run the regression against it, but it seemed
> to work, and is only a two line change in current source.
This patch needs more work. You are assuming that integer division on
negative numbers works the same everywhere, which it most definitely
does not (the direction of truncation was unspecified until C99).
The overflow check will fail on platforms where negative results
truncate towards minus infinity. So we need a different way of checking
for overflow.
Right off the bat I'm not coming up with an implementation that's both
portable and able to accept INT64_MIN, but this has got to be a solved
problem. Look around, maybe in the GNU or BSD C libraries...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2001-08-07 20:10:20 | Re: FW: [JDBC] BIGINT vs Java's long |
Previous Message | August Zajonc | 2001-08-07 19:43:15 | Re: Client Side Connection Pooling |