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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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