Re: Problems with lposix on win32
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Problems with lposix on win32
- From: Rici Lake <lua@...>
- Date: 2006年1月16日 10:07:54 -0500
On 16-Jan-06, at 9:43 AM, Roberto Ierusalimschy wrote:
* malloc: as far as I know, a correct malloc should not change errno.
An error in malloc generates a MEMERR, so errno is not used.
Sadly, that's not true.
"The value of errno is zero at program startup, but is never set to
zero by any library function." (ISO/IEC 9899:1999, page 186)
(So, it may change errno, but only to another error code...)
The point is that a *successful* malloc could change errno to any value
(other than 0). (The value of errno is undefined after a successful
call to any Posix function which is not specifically documented to not
change errno.)
So correct code would be something like:
int saved_errno = 0;
int rc = 0;
rc = some_function();
if (rc == -1) saved_errno = errno;
...
lua_pushinteger(L, saved_errno);
By the way, the requirement that errno be set to 0 at startup has been
dropped from IEEE Std 1003.1-2001. There wasn't much point, anyway.
I agree with ET: errno is an awful mechanism for error reporting.
I guess we all agree on this point. But does C have another mechanism
that we could use?
The best API design I know of is to associate errors with objects, as
the standard C library does for file errors. That's manageable in a
binding interface if there is always an object available to attach an
error indication to, and that was the source of my musings about making
open a method of a directory object. (With the understanding that an
implementation does not have to provide more than one directory object;
an embedded system without directories would provide only the "root"
object, which would be the same as the "cwd" object.)