Message-Id: <5.0.1.4.0.20001125113859.00a4a0a0@pop5.banet.net>
X-Sender: usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Sat, 25 Nov 2000 11:51:10 -0500
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: "Peter J. Farley III" <pjfarley AT banet DOT net>
Subject: Re: How are include/*.h headers maintained?
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <7263-Sat25Nov2000125836+0200-eliz@is.elta.co.il>
References: <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001125025008 DOT 00a4bc20 AT pop5 DOT banet DOT net>
 <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001125013858 DOT 00a5dcc0 AT pop5 DOT banet DOT net>
 <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001125013858 DOT 00a5dcc0 AT pop5 DOT banet DOT net>
 <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001125025008 DOT 00a4bc20 AT pop5 DOT banet DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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)