Bug 46624 - istream::sync() doesn't work
Summary: istream::sync() doesn't work
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.5.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-23 17:49 UTC by MyAdEss
Modified: 2010-11-23 22:00 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
information file generated by g++-4.5 -v -save-temps sync.cpp (60.06 KB, application/octet-stream)
2010-11-23 17:49 UTC, MyAdEss
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MyAdEss 2010-11-23 17:49:50 UTC
Created attachment 22500 [details]
information file generated by g++-4.5 -v -save-temps sync.cpp

istream::sync() doesn't work properly. It returns zero value, so it looks like it synchronizes the buffer, but it does not.
When I ask user for input, I should be able to get part of this input and ignore the rest with cin.sync(). Then I should be able to ask for input again without reading those old ignored characters.
However when I do that, no characters are discarded and user is not even asked for the second input.
I have this problem with g++ versions 4.5.1-7ubuntu2 and 4.4.4-14ubuntu5.

----------- Example -----------
-----source------
char a,b;
cout << "Enter word: ";
a = cin.get();

cin.sync();

cout << "Enter another word: ";
b = cin.get();

cout << a << " " << b;
-----expected input------
Enter word: hello
Enter another word: world
----expected output------
h w
-----real input------
Enter word: hello
Enter another word:
-----real output------
h e
-----------

----------- sync.cpp: -----------
#include <iostream>
using namespace std;

int main () {
  char first, second;

  cout << "Please, enter a word: ";
  // this gets the first character of the first word
  first=cin.get();
  
  // this should discard all unread characters
  cin.sync();

  cout << "Please, enter another word: ";
  // this should wait for another word, but it gets
  // the second character of the first word instead
  second=cin.get();

  cout << "The first word began by " << first << endl;
  cout << "The second word began by " << second << endl;

  return 0;
}

----------- Generated .ii file as attachment -----------

----------- Output of g++-4.5 -v -save-temps sync.cpp -----------
Using built-in specs.
COLLECT_GCC=g++-4.5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.1-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.1 (Ubuntu/Linaro 4.5.1-7ubuntu2) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/cc1plus -E -quiet -v -D_GNU_SOURCE sync.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=x86-64 -fpch-preprocess -fstack-protector -o sync.ii
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.5
 /usr/include/c++/4.5/x86_64-linux-gnu
 /usr/include/c++/4.5/backward
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/include
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/cc1plus -fpreprocessed sync.ii -quiet -dumpbase sync.cpp -mtune=generic -march=x86-64 -auxbase sync -version -fstack-protector -o sync.s
GNU C++ (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (x86_64-linux-gnu)
        compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (x86_64-linux-gnu)
        compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 50e33501336f77ceb788d88860a1807b
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -V -Qy --64 -o sync.o sync.s
GNU assembler version 2.20.51 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.20.51-system.20100908
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/:/usr/lib/gcc/x86_64-linux-gnu/4.5.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.5.1/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/:/usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.5.1/collect2 --build-id --no-add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.5.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.5.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../.. sync.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/4.5.1/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.5.1/../../../../lib64/crtn.o

----------- uname -a -----------
Linux floop-kubuntu 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:45:36 UTC 2010 x86_64 GNU/Linux
My distribution is Kubuntu 10.10 64-bit

Thank you for your help.
Comment 1 Jonathan Wakely 2010-11-23 18:00:30 UTC
I don't see a requirement in the standard for the behaviour you expect.

istream::sync() calls streambuf::sync(), the behaviour of which depends on the specific streambuf type.  Since the type of streambuf used by std::cin is unspecified, the behaviour of cin.sync() is also unspecified.
Comment 2 MyAdEss 2010-11-23 20:01:30 UTC
(In reply to comment #1)
> I don't see a requirement in the standard for the behaviour you expect.
> 
> istream::sync() calls streambuf::sync(), the behaviour of which depends on the
> specific streambuf type.  Since the type of streambuf used by std::cin is
> unspecified, the behaviour of cin.sync() is also unspecified.

Oh, I guess you are right. Standard doesn't specify behaviour for cin's streambuf type. It is implementation-specific. It worked for me on different platforms and compilers. I was also reading it's definition on cplusplus.com but I should look what standard says.
Anyway, it would be nice if it worked as I expected. cin.ignore() statements inside loops could be avoided.

Thank you for your fast reply.
Comment 3 Jonathan Wakely 2010-11-23 22:00:07 UTC
(In reply to comment #2)
> 
> Oh, I guess you are right. Standard doesn't specify behaviour for cin's
> streambuf type. It is implementation-specific. It worked for me on different
> platforms and compilers. I was also reading it's definition on cplusplus.com
> but I should look what standard says.

cplusplus.com has always been a poor reference

> Anyway, it would be nice if it worked as I expected. cin.ignore() statements
> inside loops could be avoided.

It couldn't be avoided in portable code, because other implementation still might not have the semantics given by cplusplus.com