public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/49506] New: reusing a file stream object will always get eof after openning
@ 2011-06-22 20:31 gzljg at hotmail dot com
  2011-06-22 20:42 ` [Bug libstdc++/49506] " pinskia at gcc dot gnu.org
  2011-06-26 15:37 ` redi at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: gzljg at hotmail dot com @ 2011-06-22 20:31 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49506

           Summary: reusing a file stream object will always get eof after
                    openning
           Product: gcc
           Version: 3.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: gzljg@hotmail.com


Created attachment 24581
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24581
test programe to reproduce the file stream open-eof bug

It seems that if I reuse a std::ifstream object by "open(another_file)" it will
always return EOF right away. See the attached file for details.

I had confirmed this can be reproduced with gcc 3.3.3 but NOT in gcc 4.3.3.
(Not sure which exact version fixed the problem -- I had searched the similar
bug description but could not find one ).

In a good case, the test program should return 0 silently.
In a bad case, the test program print out "eof" and some of the bits of the
stream state and return 1;


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/49506] reusing a file stream object will always get eof after openning
  2011-06-22 20:31 [Bug libstdc++/49506] New: reusing a file stream object will always get eof after openning gzljg at hotmail dot com
@ 2011-06-22 20:42 ` pinskia at gcc dot gnu.org
  2011-06-26 15:37 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: pinskia at gcc dot gnu.org @ 2011-06-22 20:42 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49506

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.3

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-06-22 20:42:02 UTC ---
>I had confirmed this can be reproduced with gcc 3.3.3 but NOT in gcc 4.3.3.


Well 3.3.3 is old and no longer supported.  So this has been fixed already


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/49506] reusing a file stream object will always get eof after openning
  2011-06-22 20:31 [Bug libstdc++/49506] New: reusing a file stream object will always get eof after openning gzljg at hotmail dot com
  2011-06-22 20:42 ` [Bug libstdc++/49506] " pinskia at gcc dot gnu.org
@ 2011-06-26 15:37 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2011-06-26 15:37 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49506

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-06-26 15:36:45 UTC ---
This was DR 409, which wasn't resolved when GCC 3.3 was released
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3286.html#409


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-06-26 15:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-22 20:31 [Bug libstdc++/49506] New: reusing a file stream object will always get eof after openning gzljg at hotmail dot com
2011-06-22 20:42 ` [Bug libstdc++/49506] " pinskia at gcc dot gnu.org
2011-06-26 15:37 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).