RFC Fix for 9964.cc and 9507.cc on ia64-hpux

[Zack Weinberg]

The libstdc++ tests 27_io/basic_filebuf/close/char/9964.cc and
27_io/basic_filebuf/open/char/9507.cc have been failing on ia64-hpux
for a very long time (specifically, they broke in between 3.3.2 and
3.3.3 - they weren't called that then, but they were present and
failing).  The majority of the problem is bad test case code.
However, there are also severe issues with _M_open_mode.  The
following patch attempts to fix both.

In 9507.cc, we want to open a FIFO with ios_base::ate so that it will
try to seek and fail.  The bug logs clearly indicate that the topic of
the test is a successful open but a failed seek.  Now, the current
libstdc++ basic_filebuf is a wrapper around stdio.  There is no code
string you can pass to fopen() which will make it call open() with
O_WRONLY and not O_TRUNC.  The HPUX kernel rejects O_WRONLY|O_TRUNC on
a FIFO (errno set to EINVAL).  The VERIFY()s succeed in this case,
since you do get a closed stream, but the reader process blocks
forever waiting for *someone* to open the other end of the FIFO, which
makes the test time out.  9964.cc is the same way, only here we get an
explicit failure (and then the test times out).

The cure proposed in this patch is to use in|out|ate (9507) or in|out
(9964) which corresponds to "r+" and O_RDWR handed down to the kernel.  
The HPUX kernel is happy with this.  I've also added calls to alarm()
and wait() to ensure that the tests never run for more than ten
seconds nor do they leave child processes hanging around.

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
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
ios_base::ate.

_M_open_mode gets the "Not Helping" award - it is coded in a severely
obfuscated fashion which makes it next-to-impossible to tell whether
it is actually producing the correct fopen() code strings from
openmode flags.  It is also doing somewhat more work than is
necessary, and it has no error handling whatsoever.  Pass in a
combination of flags that it doesn't handle, and you get a garbage
second argument to fopen.  I have gutted and rewritten it to hew
strictly to the table in [lib.filebuf.members]/2.  Unfortunately, this
constitutes an ABI change since _M_open_mode was exported.  I've
handled this by giving the rewritten function a new name, making it
static in basic_file_stdio.cc, and providing a wrapper under the old
name and interface (it doesn't actually *implement* the old interface
- the __rw_mode and __p_mode args are ignored - but no one should be
calling this function anyway).  I would like to dispense with the
wrapper, but I don't know if it's safe.

So, comments?  Ideally I would like to apply variations on this patch
to the 3.3 and 3.4 branches as well as mainline.

Bootstrapped ia64-hpux.

zw


        * config/io/basic_file_stdio.cc (fopen_mode): New static
        function. 
        (__basic_file<char>::sys_open, __basic_file<char>::open):
        Use fopen_mode, not _M_open_mode.
        (__basic_file<char>::_M_open_mode): Now just a
        backward-compatibility wrapper around fopen_mode.
        * config/io/basic_file_stdio.h: Wrap _M_open_mode in
        _GLIBCXX_DEPRECATED.

        * testsuite/27_io/basic_filebuf/close/char/9964.cc:
        Call fb.open with ios_base::in|ios_base::out, not
        ios_base::out|ios_base::trunc.  Set alarms to prevent
        hanging.  Wait for child process.

        * testsuite/27_io/basic_filebuf/open/char/9507.cc:
        Call fbuf.open with ios_base::in|ios_base::out|ios_base::ate, 
        not ios_base::out|ios_base::ate.  Set alarms to prevent
        hanging.  Wait for child process.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-patch
Size: 8291 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20040203/149423ea/attachment.bin>