Date: Sat, 25 Nov 2000 12:58:37 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: pjfarley AT banet DOT net
Message-Id: <7263-Sat25Nov2000125836+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC: djgpp-workers AT delorie DOT com
In-reply-to: <5.0.1.4.0.20001125025008.00a4bc20@pop5.banet.net>
	(pjfarley AT banet DOT net)
Subject: Re: How are include/*.h headers maintained?
References: <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>
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

> 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.