From: Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
Message-Id: <199803191402.PAA11064@propus.lu.erisoft.se>
Subject: Re: Where to get the latest sources for djtar
To: djgpp-workers AT delorie DOT com (DJGPP-WORKERS)
Date: Thu, 19 Mar 1998 15:02:33 +0100 (MET)
In-Reply-To: <Pine.SUN.3.91.980318175514.22186A-100000@is> from "Eli Zaretskii" at Mar 18, 98 06:00:23 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

Here follows what I can remember of my post that was intended for Eli and 
djgpp-workers. Unfortunately I only sent it to Eli, without saving a copy
for myself.

Any references in one of my previous messages to "my previous post" can 
be thought of as references to this post.

> It doesn't apply to floppies, but the code bloat is still there...

I was thinking of hard drives. I wouln't call a call statfs code bloat.

> For that matter, none of the libc functions supports FAT32 drives as yet, 
> so you could claim that mkdir doesn't have to, either, at least for now.

This would be corrected when statfs is corrected.


Now to my main point:

I think libc should set errno to some better value than what DOS provides.

As for the ineffiecency of it: this is when an error occurs, hence I think
it's ok spend some (or even quite a lot of) time providing better 
diagnostics. 

Either libc spend some time to provide better errno, which an application
can act on or the application spend some time to get this information.

Supposing libc provides better errno, if the application program decides
to ignore this information then it will burn some time - so what? Why 
shouldn't that time be spent in libc for better diagnostics instead of
in the application (either doing what libc is proposed to do; or even
worse, trying again and again).


I think this is approximately what I said in my message.


Thanks,

							MartinS