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=hpHRCmgYnMmchdaodbfHJ6TxssNisaahhszm/YyGB5o=; b=IK99nHlqDJVZ
	j7iGBCnhmjG9iu+oaFIJ9C2tDtl8WlqelFiBXzzq8iXPMKIsdcC8I98qOskesGVvsiayyWoMvicAY
	mJHsp+kVJYbUa/GJDGlqOOh8PsI3grXSZycGzJkKlTTPLsz1Hstm4zjZblWNn9MMSCpa86eC0GM8X
	qFks8a3DHQk3zhAKJ88EZT2K3UCJO2yGmmZfyJ43vqRGVcvyrmFU6PRKkRUv3HnaZUyajg/Rb4Ama
	RUX5BIHZ4+9pEdvLRdOLYsy0Ic8a5n+f8R2nonf/9Jp7iWy/93LCs+wDbp94150mg+5tycgBWQUey
	lkLJZ2XRxcxm7deYqUgFWw==;
Date: Sat, 11 May 2024 14:24:05 +0300
Message-Id: <86zfsw1tii.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, djgpp AT delorie DOT com
In-Reply-To: <20240511110655.rux4ltfvw62xzrdm@pali> (message from Pali on Sat,
	11 May 2024 13:06:55 +0200)
Subject: Re: Fix passing fcntl and ioctl variadic arguments to file system
 extension API
References: <20240509182019 DOT mrbfcyv4jhl3w34x AT pali>
 <867cg03azy DOT fsf AT gnu DOT org> <20240511110655 DOT rux4ltfvw62xzrdm 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: Sat, 11 May 2024 13:06:55 +0200
> From: Pali <pali AT pali DOT im>
> Cc: DJ Delorie <dj AT delorie DOT com>, djgpp AT delorie DOT com
> 
>   __FSEXT_Function *func = __FSEXT_get_function(fd);
>   if(func)
>   {
>     int rv;
>     if (__FSEXT_func_wrapper(func, __FSEXT_ioctl, &rv, fd))
>        return rv;
>   }
> 
> What can happen is:
> 
> 1) fd is not of fsext type
>    - func is NULL and the fsext condition is skipped
>    - _unix_ioctl continue
> 
> 2) fs is of fsext type and fsext function success
>    - func is called and then "return rv" is called
>    - _unix_ioctl finish execution
> 
> 3) fs is of fsext type but fsext function does not handle _unix_ioctl
>    - func is executed but returns false
>    - _unix_ioctl continue
> 
> But option 2 cannot happen because during execution of ioctl function
> (before it passed control to _unix_ioctl function) it was already
> checked that fd is either not of fsext type OR fsext does not have
> particular ioctl code.
> 
> So what can happen is either option 1 or 3. Which means that fsext
> cannot handle particular ioctl code and so I think that it does not make
> sense to call fsext function.

So if we ever change the calling code to do something that would
invalidate the conclusion that the two calls to __FSEXT_func_wrapper
do exactly the same, Someone(TM) will need to remember to go back and
reinstate the removed call?  Is that reasonable?

But if DJ agrees with you, I won't argue.