Date: Thu, 19 Mar 1998 20:31:43 -0500 (EST)
Message-Id: <199803200131.UAA10178@delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: Martin DOT Stromberg AT lu DOT erisoft DOT se
CC: djgpp-workers AT delorie DOT com
In-reply-to: <199803191510.QAA11587@propus.lu.erisoft.se> (message from Martin
	Stromberg on Thu, 19 Mar 1998 16:10:21 +0100 (MET))
Subject: Re: mkdir and errno
Precedence: bulk


> From: Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>
> 
> Are you opposed to any change of errno's setting in libc's mkdir?

That depends on the impact and side effects.  Has anyone thought of
the impact of non-compatible return values from Borland/MSC compilers?
How many bytes are added to a program by this patch?  What's the time
difference?

Gather the facts first.  Then discuss them.  *Then* decide if it makes
sense.  While I do have veto power over djgpp changes, using it is
rarely the right thing to do.

> If you don't want a call to statfs() in mkdir's source, is it ok to 
> call INT21/0x36 directly?

If it doesn't work under VFAT, it doesn't make sense to add it.

> How about the setting of errno to ENAMETOOLONG when it is running 
> under plain DOS and the path exceeds the limit?

I'm not sure this is worth the effort.  First, you have to detect the
file system limitations, then check the length of the string (after
canonicalizing it).  Is it so bad to return EACCES for this case?
What does Borland return?

> I didn't get any feedback on whether it is bug or feature that the call
> to access() clobbers errno. So is it a bug or feature?

Any library function may change errno at any time for any reason.
This is not a bug or a feature, but a rule.