Re: Strange interval arithmetic
От | Greg Stark |
---|---|
Тема | Re: Strange interval arithmetic |
Дата | |
Msg-id | 87br00h842.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: Strange interval arithmetic (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Strange interval arithmetic
Re: Strange interval arithmetic |
Список | pgsql-hackers |
Greg Stark <gsstark@MIT.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 oferrno 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
В списке pgsql-hackers по дате отправления: