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

Re: Strange interval arithmetic

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Greg Stark <gsstark(at)MIT(dot)EDU>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:31:41
Message-ID: 87br00h842.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Greg Stark <gsstark(at)MIT(dot)EDU> 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
> directory" ...

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.

The problem is that the function can call other libc functions, which may in
turn return errors. But these errors might be incidental and handled by the
function you're calling.

The typical case of this is calling printf which first calls isatty(). printf
then returns success but leaves errno set to ENOTTY. And programs that check
errno without checking the return valule -- even if they clear it before
calling printf -- mysteriously print "Not a Typewriter" after correctly
printing the data.

The SUS standard protects against this though by only allowing this to happen
for functions that don't themselves use errno to signal errors:

  The value of errno may be set to nonzero by a library function call
  whether or not there is an error, provided the use of errno is not
  documented in the description of the function in this International
  Standard.

Older platforms may still have this behaviour, but strtol seems like a pretty
innocuous case. It's hard to imagine strtol needing to call much else. And
strtol was an ANSI addition so one imagines most platforms got it right from
the beginning.

-- 
greg


In response to

Responses

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2005-12-01 20:37:09
Subject: Re: 8.1, OID's and plpgsql
Previous:From: Tom LaneDate: 2005-12-01 20:26:32
Subject: Re: [ADMIN] ERROR: could not read block

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-12-01 20:37:22
Subject: Re: [HACKERS] Strange interval arithmetic
Previous:From: Marc G. FournierDate: 2005-12-01 19:09:07
Subject: Re: [PATCHES] aclchk.c refactor

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