Date: Thu, 14 Dec 2000 11:31:46 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Peter J. Farley III" <pjfarley AT banet DOT net>
cc: djgpp-workers AT delorie DOT com
Subject: Re: Locking fcntl changes #2
In-Reply-To: <5.0.2.1.0.20001213204815.025a7ec0@pop5.banet.net>
Message-ID: <Pine.SUN.3.91.1001214113129.25353C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Wed, 13 Dec 2000, Peter J. Farley III wrote:

>  >So I think it would be easier for you to dump filelength and use
>  >llseek in all cases, including the FAT16 branch.  In other words,
>  >expand filelength's guts inline and replace lseek with llseek.
> 
> Or just change filelength to use llseek.  Isn't that a better 
> solution?

Perhaps.  But I didn't want to add yet another cleanup job to what you
need to do ;-)

> Of course, if the definition of filelength insists on a long 
> result, wrong results can still be returned.  If that's the case, what 
> about an "l" version of filelength (though "lfilelength" seems a bit of 
> a cumbersome name, IMHO) which returns a long long?

filelength is a compatibility function, so a variant for large files
should follow name conventions on the platforms which have such a
variant.  Can someone look and suggest a name?