Date: Tue, 10 Mar 1998 13:42:09 +0200 (IST) From: Eli Zaretskii To: Vik Heyndrickx cc: djgpp-workers AT delorie DOT com Subject: Re: errno constants in In-Reply-To: <350522C1.4929@rug.ac.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 10 Mar 1998, Vik Heyndrickx wrote: > 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) I don't see any big problems with that. Every DOS call already has the code (the one that gets plugged into __doserr_to_errno to yield errno), so you need only to assign it to _dos_errno instead of forgetting about it. > and documenting it. Documenting it might be a nice idea, but IMHO it is not necessarily a must, since we don't even document what values of errno can be gotten after calling each libc function. As for the possible values of _dos_errno, if you don't have time to list them (a list is available in the Interrupt list), just send people to some reference material. > This is much more than where I originally suggested it for. You should have thought about this before suggesting ;-). > This also is an encouragement to the user to use the DOS functions > instead of the standard functions. That's no good. I don't see how does it encourage this. Can you explain? > > 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. So what else is new? Look in the sources for GNU Tar, you will see a myriad of comments like "/* FIXME: errno should be read-only */". > 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. Yes, it will.