Date: Fri, 31 May 2002 10:11:14 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: "Richard Dawe" <rich AT phekda DOT freeserve DOT co DOT uk>
Message-Id: <6137-Fri31May2002101114+0300-eliz@is.elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com
In-reply-to: <E17D9SW-0000RF-00@phekda.freeserve.co.uk>
	(rich AT phekda DOT freeserve DOT co DOT uk)
Subject: Re: Patches for build with gcc 3.1 - FSEXT chunk
References:  <E17D9SW-0000RF-00 AT phekda DOT freeserve DOT co DOT uk>
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: Wed, 29 May 2002 20:56:01 +0100
> From: "Richard Dawe" <rich AT phekda DOT freeserve DOT co DOT uk>
> 
> There's scope for making the wrapper functions common, e.g. by making
> them library functions, e.g. __FSEXT_call_open_handlers2() which has
> a variable number of parameters rather than taking a va_list?

How about defining an inline function in some header file private to
the library?

> ioctl() and fcntl() are hard to fix, because they take
> a command parameter and a va_list, but we somehow need to include
> the command parameter in the va_list we pass to the FSEXT functions.
> Is there any way of inserting a parameter into a va_list. I had
> a look at the C99 standard, but there seems to be no way to do.
> 
> The approach below with ioctl() is that we have two va_lists -
> one including the command parameter, one without. We pass
> command+others to the FSEXT. But gcc gives a warning in this case,
> because the command parameter is not the last one before '...'.

It strikes me that we should simply compile ioctl with less stringent
warning switches, and leave the code as it was.  It doesn't make sense
to try to comply with the crazy GCC 3.x criteria for warning-free code
in a platform-specific function such as ioctl and fcntl.  We _know_
what we are doing, and we _know_ there's no chance that code will ever
be portable.

The rest of the changes seem okay by inspection, but please make sure
that whatever changes you make in FSEXT-related parts don't break
existing uses of FSEXT, like dbgcom.c, GNU `ls', Ispell, etc.