Mail Archives: djgpp-workers/2000/11/25/05:58:46
> Date: Sat, 25 Nov 2000 03:33:05 -0500
> From: "Peter J. Farley III" <pjfarley AT banet DOT net>
>
> >Why do you need the string descriptions of DOS errors? Isn't it
> >enough to pass the DOS error code to __doserr_to_errno and then use
> >strerror or perror?
>
> Well, for one thing I did *not* know that __doserr_to_errno
> existed... It seems not to be documented anywhere in the info docs.
That's a documentation bug.
> I tried it in the test program, and it seems (IMHO) less useful for
> the detailed information one needs at this level.
If you want all the info _dosexterr returns, then __doserr_to_errno is
indeed not enough for you. But in the final version of fcntl you will
have to map the errors to one of the possible values of errno, which
is what __doserr_to_errno does.
> The int21/5C call returns one of
> four error values. Here are those values and the __doserr_to_errno
> substitutes:
>
> 01h (1) function number invalid EINVAL Invalid argument
> 06h (6) invalid handle EBADF Bad file descriptor
> 21h (33) lock violation EPERM Operation not permitted
> 24h (36) sharing buffer overflow ENOLCK No locks available
Pretty good mapping, I'd say, considering the total inconsistency
between DOS and Posix error code. Don't you think so? ;-)
> In the __doserr_to_errno mapping, there are 16 different DOS errors
> that result in EPERM, 3 that result in EBADF, 2 that result in ENOLCK
> and 102 that result in EINVAL.
This is inevitable: the error codes parameterization in DOS and Unix
is very different. The large number of error codes mapped to EINVAL
is the primary evidence of how hard it is to find a meaningful
mapping.
We could, of course, invent many more E* symbols, with associated
error message strings that would match the DOS codes more closely, but
those E* symbols could only be used in DJGPP programs.
> But can it hurt to have more DOS-specific messages available if we
> want/need them?
No, it can't hurt. So if you need such a function for your needs, by
all means go ahead and add it.
> Well, I'd like to add it to src/docs/kb/wc204.txi, but I only have
> src/docs/kb/wc20[123].txi from djlsr203.zip. Is there somewhere I need
> to go to get a v204 WIP zipfile?
There is not zip file for WIP, but you can get each file via anonymous
CVS, see http://www.delorie.com/djgpp/cvs.html.
However, in the particular case of wc204.txi, you don't need to submit
a patch to the latest version in the CVS tree (if you don't want to
mess with installing a network-aware CVS client). Just write a
fragment for wc204.txi and submit it as plain text, not as diffs.
> There is a .txh file for dosexterr already, and that seems to be a
> logical place to add it. There will be less duplication of text that
> way, since the errors are already listed in the existing file.
Yes.
> I didn't know if [*.txh files] had anything to do with the
> .h files or not, but I have seen packages (perl is an example) where
> docs and code are in one file, which some make-time process separates
> into generated files.
It would be nice to have kind of literal programming in place for
DJGPP, but no one has yet volunteered to make it happen.
- Raw text -