Mail Archives: djgpp-workers/1998/03/10/06:42:53
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.
- Raw text -