This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mmap stdio breaks GNU ld

Geoff Keating <> writes:

>> From: Roland McGrath <>
>> Date: Fri, 18 Jan 2002 18:07:38 -0500 (EST)
>> However, many programs over the years have assumed it and it has always
>> been true.  Such assumptions are likely to produce subtle problems.  I
>> think we should preserve the property of fopen not moving the file position
>> for the sake of compatibility.
> I think we should either document such things as reliable properties
> of the library, or actively try to break them.  Otherwise you end up
> with programs relying on things "because it's always worked".  Indeed,
> I think we should try harder to vary things like the details of the
> stdio implementation, internal glibc symbols, and the details of the
> malloc implementation, because these are areas where we've repeatedly
> had problems with programs assuming things that are not part of the
> specification, and the longer that such things are unchanged the
> louder the complaints will be in the end.

I would prefer it the other way round: Let's document now what we not
guarantee.  That allows us to break it when needed and everybody
should be aware of it.  I'm totally opposed to break programs just for
the sake of it.

> In the case of the file position after fopen, it seems like
> documenting this would limit glibc's freedom to cache file contents;
> and there are already documented ways to synchronise stdio streams
> with the underlying file.  It's hard to argue that this should be a
> permanent, documented, property of the libc.

Do you mean fclean?

 Andreas Jaeger
  SuSE Labs

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]