Mail Archives: djgpp-workers/2000/11/25/11:50:15
At 12:58 PM 11/25/00 +0200, Eli Zaretskii wrote:
<Snipped>
>> 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.
Glad it's not me failing to RTFM, which is usually the case... :)
>> 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.
In that case, I would like to change the mapping of DOS error 24h (33)
to EACCES from EPERM, since that is what fcntl is supposed to return in
those cases where a lock cannot be obtained. Is it all right for me to
change the __doserr_to_errno mapping for this? If not, I will just
code the EACCES errno explicitly in the new fcntl.
>> The int21/5C call returns one of
>> four error values. Here are those values and the __doserr_to_errno
>> substitutes:
<Snipped>
>Pretty good mapping, I'd say, considering the total inconsistency
>between DOS and Posix error code. Don't you think so? ;-)
Yes, I do, except for 24h :)
>> 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.
Agreed, this is a better solution, particularly for portability
reasons.
>> 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.
OK, will do.
>> 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.
Much better. I have no desire to move to CVS at this time, thank you.
Are the texinfo conventions and style used in these doc files
documented anywhere in a concise manner? This will be the first time I
am creating such documentation, so I'd like to Do The Right Thing, if
possible.
>> 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.
Good.
>> 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.
I know you meant to say "literate" there, but I won't Carp::carp about
it, as the perlmongers would say... :)
Thanks again for your help. Back to programming and documenting so I
can get this baby out the door.
Bye for now.
---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
pjfarley AT banet DOT net)
- Raw text -