X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Recipient: dj AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
	s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
	mime-version; bh=MnIzGzijbkzw1UCG+e1MxXmSRoqwceWUSlY+uNFdKF8=; b=En6Tcoq+wxv6
	4ECWtCxVyflSb9/cEmiEmE1FyzqUMkuklx0Awu8+gB7zlivr7kTQph5BcWHvcAeIjudLzj1ioAEmt
	nD81qrByrv8xScfuYoCz3zsmh6D2Rr7nmDzBhT+2q8sjWd2o4YAPW+P5ltoZyouAgoEy8NiuPhfwE
	s8NSqM3BfBEJphSjSC5BL5Ax5nXOXRDsRqxFk3HI1ywWuIsRg7BzjXlfSbWS+xcVPTUk1Ja5stkqk
	RdXSligkHBwF9RDsRStqGQDClhdADZlFdFB+bWQGWt2V6e7k18YX4FRLRESdY4SHeNXzneQtMYY7A
	7SYDz295LP8QXAjsbC4Vvg==;
Date: Sun, 14 Apr 2024 08:39:55 +0300
Message-Id: <86h6g4o638.fsf@gnu.org>
From: "Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To: Pali <pali AT pali DOT im>
Cc: dj AT delorie DOT com, sezeroz AT gmail DOT com, djgpp AT delorie DOT com
In-Reply-To: <20240413225744.sxdwqpaipq5acj3n@pali> (message from Pali on Sun,
	14 Apr 2024 00:57:44 +0200)
Subject: Re: Error handling in __djgpp_set_page_attributes()
References: <20240413103741 DOT wpz7cy3ff3uaflo6 AT pali>
 <86edb9pjka DOT fsf AT gnu DOT org>
 <20240413120109 DOT bbs63syonlprvmw4 AT pali>
 <865xwlpio5 DOT fsf AT gnu DOT org>
 <20240413122345 DOT sq2ua43ugmshrlhv AT pali>
 <86v84lntr7 DOT fsf AT gnu DOT org> <20240413225744 DOT sxdwqpaipq5acj3n AT pali>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Sun, 14 Apr 2024 00:57:44 +0200
> From: Pali <pali AT pali DOT im>
> Cc: dj AT delorie DOT com, sezeroz AT gmail DOT com, djgpp AT delorie DOT com
> 
> On Saturday 13 April 2024 18:54:04 Eli Zaretskii wrote:
> > > Date: Sat, 13 Apr 2024 14:23:45 +0200
> > > From: Pali <pali AT pali DOT im>
> > > Cc: dj AT delorie DOT com, sezeroz AT gmail DOT com, djgpp AT delorie DOT com
> > > 
> > > On Saturday 13 April 2024 15:10:34 Eli Zaretskii wrote:
> > > > > +              default: /* Other unspecified error */
> > > > > +                errno = EIO;
> > > > > +                break;
> > > > 
> > > > Why EIO and not the original EACCES?
> > > 
> > > EACCES is "Permission denied" error.
> > 
> > I believe it's "Access denied" ("Permission denied" is EPERM).
> 
> EACCES is "Permission denied" error. Now I checked it via
> strerror(EACCES) call on both DJGPP and Linux runtimes.
> 
> EPERM is "Operation not permitted" error.
> 
> But this is quite interesting, I was looking at differences between
> EACCES and EPERM. Here are links to POSIX and GNU definitions:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03
> https://www.gnu.org/software/libc/manual/html_node/Error-Codes.html
> 
> My understanding is that EACCES is an error caused by rwx file access
> permission check (e.g. opening file for writing which is marked as
> read-only, without w bit) and EPERM is an error caused by limited
> ownership (e.g. killing process of other user).
> 
> So in my opinion both EACCES and EPERM are not good choices for this
> case of "other unspecified error".

EACCES is the DOS and Windows "generic" errno value, and is ubiquitous
on those two systems.  Reading Posix references will not tell you the
whole story, since the "native" error codes on DOS and Windows are
quite different, and converting them to Posix codes is not always
trivial.  That is why we see EACCES so much, and I believe that's why
the original code used it.

> > EACCES was what we returned previously, isn't it?  So why is it bad to
> > fall back on it?
> 
> Because I think that "Permission denied" error is misleading.
> 
> > EIO is basically inappropriate at least the same as
> > EACCES: there's no "I/O" here, right?
> 
> I see what you mean. I thought that EIO could be used for some generic
> error when changing page attributes, as it is doing some I/O operations
> on page tables. But I really do not know now. I/O term is mostly used
> when doing some kind of disk I/O operation.

I still think falling back on EACCES is the best way here.  Since
every error that we can reasonably interpret now has its correct errno
value, what happens in the default case is really not important, and
leaving the default as it was before is slightly more backward
compatible, IMO.