libstdc++/9408: std::string input operator waits for EOF
Kelly Fitz
kfitz@eecs.wsu.edu
Wed Jan 22 23:52:00 GMT 2003
I expect the behavior you describe, but that is not the behavior I see.
When I compile and execute that code, I get:
sal% ./moo
enter a string:
dddd<CR>
<CR>
<CR>
<CR><^D>
read: dddd
sal%
Carriage returns are not skipped, and nothing happens until I enter
ctl-D.
Here are the details of my configuration:
sal% g++3 -v -save-temps -Wall -o moo moo.ccReading specs from
/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specsc-
3.Configured with: ../gcc-3.2.1/configure --prefix=/usr/local/gcc-3.2.1
: (reconfigured) ../gcc-3.2.1/configure --prefix=/usr/local/gcc-3.2.1 :
(reconfigured) ../gcc-3.2.1/configure --prefix=/usr/local/gcc-3.2.1
--enable-threadscc /usr/local/gcc-3.2.1/lib/gThread model:
posixx-gnu/3.2.1/crtend.o /usr/lib/crtn.o
gcc version 3.2.1
/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/cpp0
-lang-c++ -D__GNUG__=3 -D__DEPRECATED -D__EXCEPTIONS -v -D__GNUC__=3
-D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=1 -D__GXX_ABI_VERSION=102
-D__ELF__ -Dunix -D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__
-D__gnu_linux__ -D__linux__ -D__unix -D__linux -Asystem=posix
-D__NO_INLINE__ -D__STDC_HOSTED__=1 -D_GNU_SOURCE -Acpu=i386
-Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__
-D__tune_pentiumpro__ moo.cc -Wall moo.ii
GNU CPP version 3.2.1 (cpplib) (i386 Linux/ELF)
ignoring nonexistent directory
"/usr/local/gcc-3.2.1/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/gcc-3.2.1/include/c++/3.2.1
/usr/local/gcc-3.2.1/include/c++/3.2.1/i686-pc-linux-gnu
/usr/local/gcc-3.2.1/include/c++/3.2.1/backward
/usr/local/include
/usr/local/gcc-3.2.1/include
/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/include
/usr/include
End of search list.
/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/cc1plus
-fpreprocessed moo.ii -quiet -dumpbase moo.cc -Wall -version -o moo.s
GNU CPP version 3.2.1 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.2.1 (i686-pc-linux-gnu)
compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.1
2.96-81).
as --traditional-format -V -Qy -o moo.o moo.s
GNU assembler version 2.10.91 (i386-redhat-linux) using BFD version
2.10.91.0.2
/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/collect2 -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o moo /usr/lib/crt1.o
/usr/lib/crti.o
/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/crtbegin.o
-L/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1
-L/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/../../..
moo.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/gcc-3.2.1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/crtend.o
/usr/lib/crtn.o
I can also send you the configuration information for another
installation (on another RedHat system) of the same version (3.2.1)
that exhibits the behavior I have described.
How should I proceed? I am trying to use this version of g++ to teach
C++ to a class of sophomores, and this very basic code from our text
doesn't execute correctly. Could we possibly have mis-configured the
compiler build? Do we need to step back to an earlier version?
Any recommendations that you can offer will be greatly appreciated.
-kel
On Wednesday, January 22, 2003, at 02:22 PM, paolo@gcc.gnu.org wrote:
> Synopsis: std::string input operator waits for EOF
>
> Responsible-Changed-From-To: unassigned->paolo
> Responsible-Changed-By: paolo
> Responsible-Changed-When: Wed Jan 22 22:22:40 2003
> Responsible-Changed-Why:
> .
> State-Changed-From-To: open->feedback
> State-Changed-By: paolo
> State-Changed-When: Wed Jan 22 22:22:40 2003
> State-Changed-Why:
> Which behaviour do you expect, exactly?
> I can't find nothing wrong with the current one:
> paolo:~> g++ 9408.cc
> paolo:~> a.out
> enter a string:
> ddddd<CR>
> read: ddddd
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-
> trail&database=gcc&pr=9408
>
Kelly Fitz
School of Electrical Engineering and Computer Science
Washington State University
kfitz@eecs.wsu.edu
More information about the Gcc-bugs
mailing list