Re: Problems with lposix on win32

[Rici Lake <lua@...>]

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.)