This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: Linux vs. libio
- To: law at cygnus dot com
- Subject: Re: Linux vs. libio
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Mon, 20 Dec 99 16:49:02 PST
- Cc: jbuck at synopsys dot com, mark at codesourcery dot com, jason at cygnus dot com, drepper at gnu dot org, gcc at gcc dot gnu dot org, libc-alpha at sourceware dot cygnus dot com
I wrote:
> If glibc and libstdc++ are to share the same structures for streams/stdio,
> then yes, they must change in lock-step. This is appropriate for
> *released* versions.
Jeff writes:
> And do you happen to know when the next release cycle is going to start? Are
> you going to volunteer to remove this code if the release cycle starts before
> glibc & gcc have merged their libio implementations? Are you going to
> volunteer to merge the two versions if Mark & CodeSourcery ultimately do not
> do the work?
Is this rhetorical or do you mean it? In case you do mean it:
If that extremely unlikely event occurred, I'd just ship the thing and no
one would care.
The reason no one would care is this: users who do not specify -fnew-abi
would not see any difference, as Mark's changes would be #ifdef'd out.
(Mark's proposal results in NO CHANGE unless libstdc++ is built with
-fnew-abi!).
People using -fnew-abi would notice that some programs that mix stdio
and iostreams don't work, and that more memory is consumed due to two
libio variant copies. This would be suboptimal but OK for a non-default,
unfinished feature.
Nevertheless, we're in violent agreement: the way to proceed is to start
out with a separate branch, then work on patches that all can accept.