From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200101071022.LAA22810@father.ludd.luth.se>
Subject: Re: FSEXTs and llseek()
In-Reply-To: <Pine.SUN.3.91.1010107120839.21289T@is> from Eli Zaretskii at "Jan 7, 2001 12:10:27 pm"
To: djgpp-workers AT delorie DOT com
Date: Sun, 7 Jan 2001 11:22:41 +0100 (MET)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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

According to Eli Zaretskii:
> 
> On Sat, 6 Jan 2001, Richard Dawe wrote:
> 
> > I've just been reading about __FSEXT_llseek. 'offset_t' is described as
> > being a 'long long'. This is OK for the input arguments to __FSEXT_llseek,
> > but how do you return the offset to the caller? The return value variable
> > for the FSEXT handler function is only an 'int'.
> 
> Bummer.  I'd say this is a strong argument for backing out FSEXT support 
> for llseek: it seems gross to punish all applications with long long 
> arithmetics just because someone might want to hook llseek.

I'm not very good at the arithmetic in casting but wouldn't keeping
the return value as an int and casting it to long long in the llseek
hooker work and then convert anything < -1 to positive work?

If this would work we would only punish the llseek() hooker.


Right,

						MartinS