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

Re: Strange interval arithmetic

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
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 20:43:05
Message-ID: 16807.1133469785@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Greg Stark <gsstark(at)mit(dot)edu> 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 the SUS strtol spec,
http://www.opengroup.org/onlinepubs/007908799/xsh/strtol.html

	The strtol() function will not change the setting of errno if
	successful.

Those who are disinclined to assume that implementations always follow
the spec may take comfort from the fact that we've been testing errno
only (without also inspecting the return value) in pg_atoi for years
without problems.

From neither point of view do I see an argument for adding a test on the
return value.  It's unnecessary according to the spec, and if you
disbelieve that strtol follows the spec, you should also be suspicious
about whether it's guaranteed to return LONG_MAX/LONG_MIN upon overflow
failure.  We have no track record that gives evidence that the latter is
universally true.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Michael FuhrDate: 2005-12-01 20:45:38
Subject: Re: Strange interval arithmetic
Previous:From: Bruce MomjianDate: 2005-12-01 20:37:22
Subject: Re: [HACKERS] Strange interval arithmetic

pgsql-patches by date

Next:From: Michael FuhrDate: 2005-12-01 20:45:38
Subject: Re: Strange interval arithmetic
Previous:From: Bruce MomjianDate: 2005-12-01 20:37:22
Subject: Re: [HACKERS] Strange interval arithmetic

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