Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<350522C1.4929@rug.ac.be>
Date:	Tue, 10 Mar 1998 12:23:45 +0100
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	djgpp-workers AT delorie DOT com
Subject:	Re: errno constants in <errno.h>
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 980310130528 DOT 4314C-100000 AT is>

Eli Zaretskii wrote:
> 
> On Tue, 10 Mar 1998, Vik Heyndrickx wrote:
> 
> > Should the djgpp user also have access to this variable or should it
> > remain private to the library core?
> 
> My idea was to make it a public variable, so applications could access it
> if and when they needed.  That's how it is implemented in other DOS
> compilers.  Of course, libc functions could use it as well.

The problems I see here is that we need to support it all the time since
the user will expect that. 
Support means assigning to it after every call available at the user
level (at least) and documenting it. This is much more than where I
originally suggested it for.

This also is an encouragement to the user to use the DOS functions
instead of the standard functions. That's no good.

> > BTW, does anyone whether know whether assigning to errno by a user
> > program is portable behaviour? From what I have read, errno could even
> > be the result of a function call (i.e. an r-value)
> 
> Yes, errno doesn't have to be an lvalue.  

In this case GCC-2.8.1 is NOT compliant. It does errno = EEXIST. As an
application program, then gcc is not allowed to do that.

The reason why I asked this, is because we therefore always can store
the DOS error code, and errno could be a call to a error-code
translation function.
But if this is going to break code? I don't know.

> For that reason, errno should be read-only on the application level.  
> The library, of course, could put the knowledge of its own internals to some
> use here.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/

- Raw text -