Come posso leggere un 0xFF in un file con libC++ istream_iterator?

Question

Si consideri il seguente codice di esempio:

#include <iostream> 

using namespace std; 

int main() 
{ 
    istreambuf_iterator<char> eos; 
    istreambuf_iterator<char> iit(cin.rdbuf()); 
    int i; 
    for (i = 0; iit != eos; ++i, ++iit) { 
    cout << *iit; 
    } 
    cout << endl << i << endl; 
} 

E un file di input contenente quanto segue: "foo \ xffbar":

$ hexdump testin 
0000000 66 6f 6f ff 62 61 72 
0000007 

Ora, per il test utilizzando clang libC++ vs gnu libstdC++:

$ make test 
clang++ -std=c++11 -stdlib=libc++ -Wall -stdlib=libc++ -o bug-libcc bug.cpp 
clang++ -std=c++11 -stdlib=libc++ -Wall -stdlib=libstdc++ -o bug-libstd bug.cpp 
./bug-libcc < testin 
foo 
3 
./bug-libstd < testin 
foo�bar 
7 

Come si può vedere la versione di libC++ pensa che 0xff sia la fine del flusso e smette di leggere. Quindi questo porta a un paio di domande.

1) Si tratta di un bug in libC++ che dovrei segnalare? Le mie ricerche su google per bug esistenti non hanno trovato nulla.

2) C'è un buon modo per ovviare a questo problema?

EDIT

Il seguente codice funziona:

#include <iostream> 
#include <fstream> 

using namespace std; 

int main() 
{ 
    ifstream ifs ("testin", ios::binary); 
    istreambuf_iterator<char> eos; 
    istreambuf_iterator<char> iit(ifs.rdbuf()); 
    int i; 
    for (i = 0; iit != eos; ++i, ++iit) { 
    cout << *iit; 
    } 
    cout << endl << i << endl; 
} 

mi porta a credere che si tratta di un problema di conversione binaria, ma questo non spiega perché libstdC++ funziona correttamente.

EDIT2

Utilizzando un file senza binario funziona bene troppo:

ifstream ifs ("testin"); 

Quindi non v'è sicuramente qualcosa di sospetto. Sembra che potrebbe essere un problema nell'implementazione di cin, non l'iteratore.

Answer 1

Sfortunatamente c'è ancora un errore in libC++ (in aggiunta a quello evidenziato da ecatmur). Ecco la soluzione:

Index: include/__std_stream 
=================================================================== 
--- include/__std_stream (revision 176092) 
+++ include/__std_stream (working copy) 
@@ -150,7 +150,7 @@ 
    { 
     for (int __i = __nread; __i > 0;) 
     { 
-   if (ungetc(__extbuf[--__i], __file_) == EOF) 
+   if (ungetc(traits_type::to_int_type(__extbuf[--__i]), __file_) == EOF) 
       return traits_type::eof(); 
     } 
    } 

Otterrò questo verificato al più presto. Scusa per l'errore. Grazie per averlo portato alla mia attenzione

Correzione Correggere la revisione 176822 al trunk svn pubblico libcxx. La correzione richiede un dylib ricompilato anche se la correzione si trova in un'intestazione.

Answer 2

L'iteratore si sta estraendo dallo stream.
Il flusso deve essere aperto con la modalità binary per impedire qualsiasi traduzione dei dati originali.

Successivamente, non utilizzare char. Il tipo char può essere firmato, non firmato o meno, a seconda del compilatore. Si consiglia di utilizzare uint8_t durante la lettura di ottetti binari.

provare qualcosa di simile:

#include <cstdint> 
using std::uint8_t; 
istreambuf_iterator<uint8_t> eos; 

Answer 3

Penso che potrebbe aver trovato un bug che è già stato risolto. This commit (da @Howard Hinnant) contiene le seguenti modifiche:

@@ -104,7 +104,7 @@ 
    int __nread = _VSTD::max(1, __encoding_); 
    for (int __i = 0; __i < __nread; ++__i) 
    { 
-  char __c = getc(__file_); 
+  int __c = getc(__file_); 
     if (__c == EOF) 
      return traits_type::eof(); 
     __extbuf[__i] = static_cast<char>(__c); 
@@ -131,7 +131,7 @@ 
       if (__nread == sizeof(__extbuf)) 
        return traits_type::eof(); 
       { 
-     char __c = getc(__file_); 
+     int __c = getc(__file_); 
        if (__c == EOF) 
         return traits_type::eof(); 
        __extbuf[__nread] = static_cast<char>(__c); 

Si noterà che la versione precedente memorizzato il valore di ritorno di getc in char, che è un no-no per la ragione precisa che confonde il valore char0xff con il valore intEOF (ovvero -1).

Il bug si applica solo a cin poiché i metodi interessati sono su __stdinbuf, che è il tipo di libC++ utilizzato per implementare solo cin; ifstream ad es. utilizza basic_filebuf<char>.

Controllare il file libcxx/include/__std_stream sul sistema per vedere se ha questo bug; se lo fa, applica la patch e dovrebbe risolverla.