NetBSD Problem Report #14432

Received: (qmail 20996 invoked from network); 2 Nov 2001 01:06:42 -0000
Message-Id: <200111020106.fA216dZ22795@turakirae.mcs.vuw.ac.nz>
Date: Fri, 2 Nov 2001 14:06:39 +1300 (NZDT)
From: Mark Davies <mark@mcs.vuw.ac.nz>
Reply-To: mark@mcs.vuw.ac.nz
To: gnats-bugs@gnats.netbsd.org
Subject: Torek stdio and gnu/lib/libstdc++ clear() method problem
X-Send-Pr-Version: 3.95

>Number:         14432
>Category:       toolchain
>Synopsis:       Torek stdio and gnu/lib/libstdc++ clear() method problem
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Nov 02 01:07:00 +0000 2001
>Closed-Date:    
>Last-Modified:  Fri Oct 13 19:20:01 +0000 2006
>Originator:     Mark Davies
>Release:        NetBSD 1.5Y 29/10/2001
>Organization:
Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
>Environment:


System: NetBSD turakirae.mcs.vuw.ac.nz 1.5Y NetBSD 1.5Y (MCS_WORKSTATION) #1: Tue Oct 30 22:54:21 NZDT 2001 mark@turakirae.mcs.vuw.ac.nz:/src/work/src/sys/arch/i386/compile/MCS_WORKSTATION i386
Architecture: i386
Machine: i386
>Description:

>How-To-Repeat:

	<how to correct or work around the problem, if known (multiple lines)>

X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4


The following little c++ program demonstrates a problem with the iostream clear
method on at least the i386 port.

#include <iostream.h>

main()
{
        char ans;

        cout << "Hello World: ";
        cin >> ans;
        cin.clear();
        cout << "Hi again: ";
        cin >> ans;
}

Compiling and running this on 1.5X, if you type CNTL-D at the first prompt,
it drops through the second and exits with the cin.clear() appearing not to
clear the EOF status on standard in. This is with the standard system g++
and the same thing happens with the 2.95.2 from pkgsrc and with the new
toolchain on 1.5Y.

This same code, compiled with various versions of g++, on Tru64 and
Solaris8 sits at the second prompt waiting for more input so its not a
general g++/libstdc++ problem but specific to NetBSD (or maybe Torek stdio
based systems).

The following little C program behaves the same as the above C++ one
(with NetBSD's behaviour being different from Solaris and Tru64)

#include <stdio.h>

main ()
{
  char ans;

  printf("Hello World: ");
  ans= getc(stdin);
  /* clearerr(stdin); */
  printf("Hi World: ");
  ans= getc(stdin);

}

If you enable the commented out clearerr(stdin) then you get consistent 
behaviour across the three UNIX systems.

Similarly the following change to the C++ program gets consistent behaviour 
across the systems:

#include <iostream.h>
#include <stdio.h>

main()
{
        char ans;

        cout << "Hello World: ";
        cin >> ans;
        cin.clear();
	clearerr(stdin);
        cout << "Hi again: ";
        cin >> ans;
}


So it appears to me that Torek stdio requires the clearerr() to clear the EOF 
status while the other stdio implementation lets you get away without doing it 
(and I have no problem with the Torek behaviour) but it also seems that 
libstdc++, when dealing with streams that are associated with stdio files is 
assuming the non Torek behaviour :-(

Interestingly the orginal little sample program works correctly on MacOS X.1 buit I couldn't see any obvious difference in the Darwin gcc source.

>Fix:

I have no idea how to fix it.  Well presumably the implementation of the clear 
method needs to work out if its dealing with a stdiostream and if so call 
clearerr() but that doesn't look at all easy to me.

cheers
mark
>Release-Note:
>Audit-Trail:
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@netbsd.org
Cc: Mark Davies <mark@mcs.vuw.ac.nz>
Subject: re: toolchain/14432
Date: Mon, 09 Oct 2006 14:15:24 +1000

 this patch is probably pretty naive, but it does make the test at
 hand work...  the #if 0'ed comment is possibly quite leading about
 the cause of this and it seems this behaviour isn't exactly well
 specified among unixes?  (i couldn't easily find SuS to tell me
 what is the right answer...)


 .mrg.


 Index: refill.c
 ===================================================================
 RCS file: /cvsroot/src/lib/libc/stdio/refill.c,v
 retrieving revision 1.13
 diff -p -r1.13 refill.c
 *** refill.c	7 Aug 2003 16:43:30 -0000	1.13
 --- refill.c	9 Oct 2006 04:11:35 -0000
 *************** __srefill(fp)
 *** 83,91 ****
 --- 83,93 ----

   	fp->_r = 0;		/* largely a convenience for callers */

 + #if 0
   	/* SysV does not make this test; take it out for compatibility */
   	if (fp->_flags & __SEOF)
   		return (EOF);
 + #endif

   	/* if not already reading, have to be reading and writing */
   	if ((fp->_flags & __SRD) == 0) {

From: Mark Davies <mark@mcs.vuw.ac.nz>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: toolchain/14432
Date: Sat, 14 Oct 2006 08:15:54 +1300

 On Monday 09 October 2006 17:20, matthew green wrote:
 >  this patch is probably pretty naive, but it does make the test at
 >  hand work...  the #if 0'ed comment is possibly quite leading about
 >  the cause of this and it seems this behaviour isn't exactly well
 >  specified among unixes?  (i couldn't easily find SuS to tell me
 >  what is the right answer...)

 Hmm, now I'll have to remember what program it was that I originally struck 
 this problem in.  Some prolog I think.

 cheers
 mark

>Unformatted:

Home	PR Database Search