On Thu, Dec 01, 2005 at 03:31:41PM -0500, Greg Stark wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Generally speaking looking at errno when you haven't received an error
> > return
> > from a libc function is asking for trouble. It could be leftover from any
> > previous libc error.
> >
>
Greg Stark <[EMAIL PROTECTED]> writes:
> Ah, I take back my taking back of this. It's still dicey to be doing it this
> way -- even if you reset errno before calling the library function.
See the rest of the thread. The I-believe-what-I-read-in-the-spec camp
may take comfort from what it says in
Greg Stark <[EMAIL PROTECTED]> writes:
> Generally speaking looking at errno when you haven't received an error return
> from a libc function is asking for trouble. It could be leftover from any
> previous libc error.
>
> That's how you get programs saying things like "strtol: No such file or
>
> Generally speaking looking at errno when you haven't received an error return
> from a libc function is asking for trouble. It could be leftover from any
> previous libc error.
Oh, sorry, just reread the code snippet and see that isn't an issue. nevermind.
--
greg
-
Tom Lane <[EMAIL PROTECTED]> writes:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > I usually check both in my own code but I noticed several places
> > where PostgreSQL doesn't, so I kept that style. I'll check both
> > if that's preferred.
>
> I'd say not --- it's more code and it makes a pos
Hmmm...is this something else that needs fixing? The doc says dates
range from 4713 BC to 32767 AD.
test=> select '11754179-08-04'::date;
date
11754179-08-04
(1 row)
test=> select '11754179-08-05'::date;
date
---
4801-01-01 BC
(1 row)
--
Mi
On Wed, Nov 30, 2005 at 06:00:07PM -0500, Andrew Dunstan wrote:
> LONG_MIN/LONG_MAX might be the actual values provided, too, mightn't
> they? checking for ERANGE seems like the only viable test.
Errno needs to be checked in any case for just that reason; the
question was whether checking *only*
Tom Lane wrote:
Michael Fuhr <[EMAIL PROTECTED]> writes:
I suppose if we check for LONG_MAX then we should also check
for LONG_MIN.
s/should/must/, which makes the code even more complicated, in order to
buy what exactly?
I don't know if any systems might set ERANGE in a non-er
On Wed, Nov 30, 2005 at 05:49:53PM -0500, Tom Lane wrote:
> The SUS saith
> http://www.opengroup.org/onlinepubs/007908799/xsh/strtol.html
>
> The strtol() function will not change the setting of errno if
> successful.
>
> Perhaps more to the point, we've been doing it that way (errno
On Wed, Nov 30, 2005 at 05:23:23PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > I usually check both in my own code but I noticed several places
> > where PostgreSQL doesn't, so I kept that style. I'll check both
> > if that's preferred.
>
> I'd say not --- it's more code
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I suppose if we check for LONG_MAX then we should also check
> for LONG_MIN.
s/should/must/, which makes the code even more complicated, in order to
buy what exactly?
> I don't know if any systems might set ERANGE in a non-error situation.
The SUS saith
On Wed, Nov 30, 2005 at 05:20:54PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > I'm looking at all the strtol() calls in datetime.c right now; I
> > haven't looked anywhere else yet. Should I bother checking values
> > that will be range checked later anyway? Time zone di
Michael Fuhr <[EMAIL PROTECTED]> writes:
> I usually check both in my own code but I noticed several places
> where PostgreSQL doesn't, so I kept that style. I'll check both
> if that's preferred.
I'd say not --- it's more code and it makes a possibly unwarranted
assumption about strtol's behavio
Michael Fuhr <[EMAIL PROTECTED]> writes:
> errno = 0;
> val = strtol(field[i], &cp, 10);
> if (errno == ERANGE)
> return DTERR_FIELD_OVERFLOW;
> Does that look okay? Or would you rather raise an error with ereport()?
Looks fine to me, at least in the routines that are for datetime st
On Wed, Nov 30, 2005 at 07:06:42PM -0300, Alvaro Herrera wrote:
> Hmm, why not check both the return value _and_ errno:
>
> val = strtol(field[i], &cp, 10);
> if (val == LONG_MAX && errno == ERANGE)
> return DTERR_FIELD_OVERFLOW;
I usually check both in my own code but I noticed several pla
Michael Fuhr wrote:
> Agreed. I'm thinking about rewriting strtol() calls in datetime.c
> to look like this:
>
> errno = 0;
> val = strtol(field[i], &cp, 10);
> if (errno == ERANGE)
> return DTERR_FIELD_OVERFLOW;
Hmm, why not check both the return value _and_ errno:
val = strtol(fi
On Wed, Nov 30, 2005 at 02:01:46PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > Any preferences on an approach? The simplest and easiest to verify
> > would be to raise an error for just this particular case; a TODO
> > item might be to change how the string is parsed to a
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Wed, Nov 30, 2005 at 12:37:40PM -0500, Tom Lane wrote:
>> Sure, send a patch ...
> Any preferences on an approach? The simplest and easiest to verify
> would be to raise an error for just this particular case; a TODO
> item might be to change how the
On Wed, Nov 30, 2005 at 12:37:40PM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> >> I see this behavior back to at least 7.3. I'd guess it's because
> >> strtol() indicates overflow by returning LONG_MAX and setting errno
> >> to ERANGE, but the code doesn't check for that.
>
Michael Fuhr <[EMAIL PROTECTED]> writes:
>> I see this behavior back to at least 7.3. I'd guess it's because
>> strtol() indicates overflow by returning LONG_MAX and setting errno
>> to ERANGE, but the code doesn't check for that.
> Is this worth looking at for the upcoming dot releases?
Sure, s
On Sun, Nov 27, 2005 at 11:27:54AM -0700, Michael Fuhr wrote:
> On Sun, Nov 27, 2005 at 08:45:18AM -0700, Michael Fuhr wrote:
> > Looks like the value is stuck at 2^31 - 1 seconds:
>
> I see this behavior back to at least 7.3. I'd guess it's because
> strtol() indicates overflow by returning LONG
On Sun, Nov 27, 2005 at 08:45:18AM -0700, Michael Fuhr wrote:
> Looks like the value is stuck at 2^31 - 1 seconds:
I see this behavior back to at least 7.3. I'd guess it's because
strtol() indicates overflow by returning LONG_MAX and setting errno
to ERANGE, but the code doesn't check for that.
On Sun, Nov 27, 2005 at 11:15:04PM +0800, Christopher Kings-Lynne wrote:
> What's going on here? Some sort of integer wraparound?
[...]
> test=# select interval '2378234234 seconds';
>interval
> --
> 596523:14:07
> (1 row)
Looks like the value is stuck at 2^31 - 1 seconds:
test=
What's going on here? Some sort of integer wraparound?
WORKS
=
mysql=# select interval '2378 seconds';
interval
--
00:39:38
(1 row)
mysql=#
mysql=# select 2378 * interval '1 second';
?column?
--
00:39:38
(1 row)
DOESN'T WORK
test=# select interval '237823
24 matches
Mail list logo
