delorie.com/archives/browse.cgi | search |
Date: | Sun, 7 Jan 2001 12:10:27 +0200 (IST) |
From: | Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> |
X-Sender: | eliz AT is |
To: | Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk> |
cc: | DJGPP workers <djgpp-workers AT delorie DOT com> |
Subject: | Re: FSEXTs and llseek() |
In-Reply-To: | <3A571924.6D5F1494@phekda.freeserve.co.uk> |
Message-ID: | <Pine.SUN.3.91.1010107120839.21289T@is> |
MIME-Version: | 1.0 |
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 |
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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |