From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Fuhr <mike(at)fuhr(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Strange interval arithmetic |
Date: | 2005-12-01 18:16:42 |
Message-ID: | 87k6eohed1.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Michael Fuhr <mike(at)fuhr(dot)org> 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 behavior.
>
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
directory" ...
The strtol() function returns the result of the conversion, unless the value
would underflow or overflow. If an underflow occurs, strtol() returns
LONG_MIN. If an overflow occurs, strtol() returns LONG_MAX. In both cases,
errno is set to ERANGE. Precisely the same holds for strtoll() (with LLONG_MIN
and LLONG_MAX instead of LONG_MIN and LONG_MAX).
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-12-01 18:18:16 | Re: Strange interval arithmetic |
Previous Message | Qingqing Zhou | 2005-12-01 17:52:48 | Re: [PATCHES] A couple of proposed pgbench changes |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-12-01 18:18:16 | Re: Strange interval arithmetic |
Previous Message | Tom Lane | 2005-12-01 17:59:16 | Re: Check for integer overflow in datetime functions |