This is the mail archive of the libc-alpha@sources.redhat.com 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 <geoffk@geoffk.org> writes:

> 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.

Everybody will at one time or another let their friends down.  But
your policy above is like deliberately screwing them over as quickly
as possible, so that they don't come to rely on you and then feel bad
when you eventually let them down.

Face it: the C language sucks.  But given the way it is, we should aim
for consistency and stability.

> 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.

How about saying we should not deliberately change the behavior unless
we actually have a good reason?


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