Skip site navigation (1) Skip section navigation (2)

Re: Strange interval arithmetic

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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


In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2005-12-01 18:18:16
Subject: Re: Strange interval arithmetic
Previous:From: Qingqing ZhouDate: 2005-12-01 17:52:48
Subject: Re: [PATCHES] A couple of proposed pgbench changes

pgsql-patches by date

Next:From: Greg StarkDate: 2005-12-01 18:18:16
Subject: Re: Strange interval arithmetic
Previous:From: Tom LaneDate: 2005-12-01 17:59:16
Subject: Re: Check for integer overflow in datetime functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group