delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/02/03/07:37:44

Date: Wed, 3 Feb 1999 14:35:48 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Martin Stromberg <eplmst AT lu DOT erisoft DOT se>
cc: DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject: Re: _llseeks()'s return value
In-Reply-To: <199902031053.LAA19755@juno.erisoft.se>
Message-ID: <Pine.SUN.3.91.990203143053.29547o-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com

On Wed, 3 Feb 1999, Martin Stromberg wrote:

> Hmm... I seem to have a problem. _llseek() is supposed to return the
> file pointer's (or whatever it's called) position. As there doesn't
> seem to be any support for seek with bigger than 2^31 offsets,
> _llseek() will have to call lseek() (potentially) several times. But
> how is _llseek() to know what to return as lseek() only returns values
> <= 2^31. 

Obviously, it will need to make 64-bit arithmetics itself, adding the 
successive offsets instead of relying on `lseek'.

> Is there some internal libc structure containing the current file
> pointer?

No.  The file pointer position is maintained by the operating system for 
each file.

It is impossible for the library to track the file pointer reliably. 
E.g., handles created by `dup' and `dup2' magically move together in
sync (they all share the same position pointer), but the library cannot
know that, especially if some of the handles belong to other processes. 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019