fopen + mmap

fopen + mmap

[Ulrich Drepper]

Before anybody gets more excited about this, I have modifications
which don't require setting the file position to the end.  The reason
I can live with this is that some more functions get simplified.  I
didn't do it initially this way since the extra code isn't justified
by the little bit of speed gain.

In general, it is not acceptable that positive development is hindered
by broken code.  There never ever was any document saying that the
file position is such and such after fopen.  People relying on it are
simply wrong.  And even though this code might now survive sometime
longer it does not mean it should not be fixed.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: fopen + mmap

[Andreas Jaeger]

Ulrich Drepper <drepper@redhat.com> writes:

> Before anybody gets more excited about this, I have modifications
> which don't require setting the file position to the end.  The reason
> I can live with this is that some more functions get simplified.  I
> didn't do it initially this way since the extra code isn't justified
> by the little bit of speed gain.

Fine.

> In general, it is not acceptable that positive development is hindered
> by broken code.  There never ever was any document saying that the
> file position is such and such after fopen.  People relying on it are
> simply wrong.  And even though this code might now survive sometime
> longer it does not mean it should not be fixed.

How should the broken code get fixed?  Can you just describe it
priefly - and I'll try to fix at least ld...

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: fopen + mmap

[Jakub Jelinek]

On Sat, Jan 19, 2002 at 11:25:07AM +0100, Andreas Jaeger wrote:
> Ulrich Drepper <drepper@redhat.com> writes:
> 
> > Before anybody gets more excited about this, I have modifications
> > which don't require setting the file position to the end.  The reason
> > I can live with this is that some more functions get simplified.  I
> > didn't do it initially this way since the extra code isn't justified
> > by the little bit of speed gain.
> 
> Fine.
> 
> > In general, it is not acceptable that positive development is hindered
> > by broken code.  There never ever was any document saying that the
> > file position is such and such after fopen.  People relying on it are
> > simply wrong.  And even though this code might now survive sometime
> > longer it does not mean it should not be fixed.
> 
> How should the broken code get fixed?  Can you just describe it
> priefly - and I'll try to fix at least ld...

fflush will move the kernel file position to the current read position.

	Jakub

Re: fopen + mmap

[Ulrich Drepper]

Jakub Jelinek <jakub@redhat.com> writes:

> fflush will move the kernel file position to the current read position.

Actually, you'll need fseek() (better fseeko()) to be sure.  It is not
guaranteed that the descriptor is at the beginning of the file.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: fopen + mmap

[Roland McGrath]

> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > fflush will move the kernel file position to the current read position.
> 
> Actually, you'll need fseek() (better fseeko()) to be sure.  It is not
> guaranteed that the descriptor is at the beginning of the file.

I don't follow your reading of the standards here.  After fopen, the new
stream's file position indicator is at the beginning of the file.
Immediately after fflush, all handles' positions match the last one used.
Since the stream was the only one used, that means the new handle created
by fileno should match the stream's position as of the fflush call,
which is the beginning of the file.

Re: fopen + mmap

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> I don't follow your reading of the standards here.  After fopen, the new
> stream's file position indicator is at the beginning of the file.

Read carefully then.  fflush is not defined on input streams.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: fopen + mmap

[Roland McGrath]

> Roland McGrath <roland@frob.com> writes:
> 
> > I don't follow your reading of the standards here.  After fopen, the new
> > stream's file position indicator is at the beginning of the file.
> 
> Read carefully then.  fflush is not defined on input streams.

If you ever wanted to make one of these discussions go faster and be less
aggravating to all parties, you could include some details with your claims.
I guess HJ's style has been an inspiration to you, because you've found it
so helpful and efficient over the years.

I don't have ANSI C on hand, but my recollection is pretty clear that
fflush is specifically defined for input streams (to discard buffered
input).  POSIX.1-1996 section 8.2.3 (p 213 in the ISO printing)
specifically mentions using fflush on input streams to synchronize the file
position.

Re: fopen + mmap

[Andreas Schwab]

Roland McGrath <roland@frob.com> writes:

|> I don't have ANSI C on hand, but my recollection is pretty clear that
|> fflush is specifically defined for input streams (to discard buffered
|> input).  POSIX.1-1996 section 8.2.3 (p 213 in the ISO printing)
|> specifically mentions using fflush on input streams to synchronize the file
|> position.

Neither C99 nor POSIX.1-2001 defines fflush on input streams, or on update
streams where the last operation was input.  SUS2 doesn't either.  In the
rational of POSIX.1-2001 it says:

    Data buffered by the system may make determining the validity of the
    position of the current file descriptor impractical. Thus, enforcing
    the repositioning of the file descriptor after fflush() on streams
    open for read() is not mandated by IEEE Std 1003.1-2001.


Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: fopen + mmap

[Roland McGrath]

> Neither C99 nor POSIX.1-2001 defines fflush on input streams, or on update
> streams where the last operation was input.  SUS2 doesn't either.

Ah, I see.  They changed the story in the past year and broke strictly
conforming POSIX.1-1996 applications.  So what you are saying is that we
need to have stdio behave differently depending on the _POSIX_C_SOURCE
value defined by the user to both be compatible with strictly conforming
POSIX.1-1996 applications, and to have different behavior that is
sufficient for strictly conforming POSIX.1-2001 applications.

Re: fopen + mmap

[Andreas Schwab]

Roland McGrath <roland@frob.com> writes:

|> > Neither C99 nor POSIX.1-2001 defines fflush on input streams, or on update
|> > streams where the last operation was input.  SUS2 doesn't either.
|> 
|> Ah, I see.  They changed the story in the past year and broke strictly
|> conforming POSIX.1-1996 applications.

Are you sure that POSIX.1-1996 has this?  The C Standard has never defined
fflush on input streams, and SUS2, which is based on POSIX.1-1996 IIRC,
doesn't have it either.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: fopen + mmap

[Roland McGrath]

> Are you sure that POSIX.1-1996 has this?  The C Standard has never
> defined fflush on input streams, and SUS2, which is based on
> POSIX.1-1996 IIRC, doesn't have it either.

I already cited the section.  It's 8.2.3(1)(g), p 213 ll 323-325:

	(g) If the stream is open with a mode that allows reading and
	    the underlying open file description refers to a device
	    that is capable of seeking, either an fflush() shall occur
	    or the stream shall be closed.

This is in the list of things to do on the first handle that are
sufficient to make the file position well-defined on the the next
handle used.

Re: fopen + mmap

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> I don't have ANSI C on hand, but my recollection is pretty clear that
> fflush is specifically defined for input streams (to discard buffered
> input).

C89 never said this and neither does C99.  I have both standards here.

> POSIX.1-1996 section 8.2.3 (p 213 in the ISO printing) specifically
> mentions using fflush on input streams to synchronize the file
> position.

This text is still present but it is clearly an error.  Unix/POSIX
directly refer to ISO C for the definition of fflush() and therefore
the function isn't defined for input streams.  You participated in
writing a standard, you know how these things can slip in.  The
OpenGroup is soon starting to collect defect reports for TR1 of XPG6.
This is something which should be reported and fixed.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: fopen + mmap

[Roland McGrath]

> C89 never said this and neither does C99.  I have both standards here.

Since I don't have copies of those, I certainly can't dispute this.  It
sure is contrary to my recollection.  But I may well be recalling a late
draft of what became ANSI C-1989, rather than the final standard.

Re: fopen + mmap

[Andreas Schwab]

Roland McGrath <roland@frob.com> writes:

|> > Are you sure that POSIX.1-1996 has this?  The C Standard has never
|> > defined fflush on input streams, and SUS2, which is based on
|> > POSIX.1-1996 IIRC, doesn't have it either.
|> 
|> I already cited the section.  It's 8.2.3(1)(g), p 213 ll 323-325:
|> 
|> 	(g) If the stream is open with a mode that allows reading and
|> 	    the underlying open file description refers to a device
|> 	    that is capable of seeking, either an fflush() shall occur
|> 	    or the stream shall be closed.
|> 
|> This is in the list of things to do on the first handle that are
|> sufficient to make the file position well-defined on the the next
|> handle used.

It only talks about a mode that _allows_ reading.  It does not make fflush
on an input stream, or an update stream that was last read, a defined
operation (you must call fclose instead to be compliant).

The whole section is about shared file descriptions, the actions to be
taken before a file descriptions may be accessed through a second handle.
It does not define the semantics of a non-shared stream.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: fopen + mmap

[Roland McGrath]

> The whole section is about shared file descriptions, the actions to be
> taken before a file descriptions may be accessed through a second handle.
> It does not define the semantics of a non-shared stream.

We are talking about a shared file description.  The fileno call makes it
shared between the stream returned by fopen and the fd returned by fileno.

Re: fopen + mmap

[Andreas Schwab]

Roland McGrath <roland@frob.com> writes:

|> > The whole section is about shared file descriptions, the actions to be
|> > taken before a file descriptions may be accessed through a second handle.
|> > It does not define the semantics of a non-shared stream.
|> 
|> We are talking about a shared file description.  The fileno call makes it
|> shared between the stream returned by fopen and the fd returned by fileno.

Yes, but the section still doesn't say anything about fflush.  Since
calling that with an input stream is an undefined operation (there is no
wording in POSIX to make it defined), you cannot use it as an action to
comply to paragraph (g).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: fopen + mmap

[Ulrich Drepper]

tb@becket.net (Thomas Bushnell, BSG) writes:

> The controversy is just about whether there is another way to get the
> particular benefit in this case without breaking the interface.

I very much prefer to wait until the outcome of the discussion which
definitely has to take place when this defect is reported.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: fopen + mmap

[Ulrich Drepper]

tb@becket.net (Thomas Bushnell, BSG) writes:

> Posix explicitly and deliberately extended fflush to input streams,
> precisely to deal with the fact that Posix also needs to specify the
> exact relationship between streams and file descriptors.

Then the description of fflush would document this.  Which is not the
case.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------