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 Mime-Version: 1.0 To: Eli Zaretskii Cc: djgpp-workers AT delorie DOT com Subject: Re: errno constants in References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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 / \ /-_-_-_-_-_-_/