This is the mail archive of the
mailing list for the GCC project.
Re: RFC Fix for 9964.cc and 9507.cc on ia64-hpux
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, Phil Edwards <phil at codesourcery dot com>, Benjamin Kosnik <bkoz at constant dot com>, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Mon, 02 Feb 2004 19:28:58 -0800
- Subject: Re: RFC Fix for 9964.cc and 9507.cc on ia64-hpux
- References: <firstname.lastname@example.org><20040203031014.GB10674@redhat.com>
Richard Henderson <email@example.com> writes:
> On Mon, Feb 02, 2004 at 06:36:08PM -0800, Zack Weinberg wrote:
>> Unfortunately, there may be some other UNIX kernel that objects to
>> opening FIFOs with O_RDWR. As I said above, there is no way to get
>> fopen() to call open() with just O_WRONLY. We cannot use an explicit
>> open() and then basic_filebuf::sys_open() because the latter ignores
^ my error: __basic_file::sys_open()
>> ios_base::ate; if this problem exists in real life, we're going to
>> have to add an entry point that does what sys_open() does but honors
> What about using open+fdopen?
As far as I can tell, __basic_file::sys_open() is the only interface
to fdopen() that libstdc++ has.
ios_base::ate is not handled at the level of __basic_file; it's
handled in basic_filebuf<_CharT, _Traits>::open, and there is no
basic_filebuf wrapper around fdopen(). Perhaps there should be one,
but I wouldn't know how to add it.