Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3A60A7A3.88C0F733@phekda.freeserve.co.uk>
Date: Sat, 13 Jan 2001 19:08:19 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.17 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: FSEXTs and llseek()
References: <200101071022 DOT LAA22810 AT father DOT ludd DOT luth DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Martin Str|mberg wrote:
[snip]
> > On Sat, 6 Jan 2001, Richard Dawe wrote:
[snip]
> > > 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'.
[snip]
> 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.

You can't really typecast the return value: 'int *' cast to 'long long *'
will lead to memory corruption, when assigning a return value.

The problem is returning a good (int-sized) offset to the FSEXT caller for
__FSEXT_llseek. If you can't return a good offset, then it's broken.

If we're agreed that it's currently broken, then I can submit a patch to
disable __FSEXT_llseek. Maybe with an appropriate comment in the sources?

Bye, Rich =]

--
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]