[gcc 3.2.3/Linux] std::wfilebuf extracts more than 1 character from a 1 byte file

• Key: STDCXX-333
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Martin Sebor
• Reporter: Mark Brown
• Component/s: 27. Input/Output
• Affects Version/s: 4.1.3, 4.2.0
• Fix Version/s: 4.2.1

Description

I get an an abort when I run the following program on Linux.

#include <cassert>
#include <fstream>
#include <iostream>

int main ()
{
    {
        std::filebuf fb;
        fb.open ("file", std::ios::out);
        fb.sputc ('a');
    }

    std::wfilebuf fb;
    fb.pubimbue (std::locale ("en_US.UTF-8"));
    fb.open ("file", std::ios::in);

    const int c[] = { fb.sbumpc (), fb.sgetc () };
    std::cout << c [0] << ' ' << c [1] << std::endl;

    assert (L'a' == c [0]);
    assert (std::wfilebuf::traits_type::eof () == c [1]);
}

test: test.cpp:21: int main(): Assertion `std::wfilebuf::traits_type::eof () == c [1]' failed.
Aborted

Comments

[Martin Sebor]

How odd. I can reproduce this but only intermittently and with different results:

$ while [ $? -eq 0 ]; do ./t; done; true; while [ $? -eq 0 ]; do ./t; done
97 -1
97 -1
97 -1
97 -1
97 8
t: t.cpp:21: int main(): Assertion `std::wfilebuf::traits_type::eof () == c [1]' failed.
Aborted
97 -1
97 -1
97 -1
97 -1
97 -1
97 -1
97 104
: t.cpp:21: int main(): Assertion `std::wfilebuf::traits_type::eof () == c [1]' failed.
Aborted

[Mark Brown]

I tried to see if I could reproduce this problem on Cygwin. My version of Cygwin doesn't have any locales so I tried to generate the en_US.UTF-8 locale using the stdcxx localedef program. I got this error:

nls$ ../bin/localedef -c -f /home/mbrown/stdcxx/etc/nls/charmaps/UTF-8 -i /home/mbrown/stdcxx/etc/nls/src/en_US en_US.UTF-8
call to system LC_ALL=C /usr/bin/locale -a >/tmp/tdf4.0 2>/dev/null: No such file or directory
Hangup

[Martin Sebor]

This is specific to Linux (couldn't reproduce on Cygwin or Solaris).

[Martin Sebor]

Reproduced reliably with gcc 4.1.1 on Linux/x86_64.

[Martin Sebor]

Set Severity to Incorrect Behavior.

[Martin Sebor]

I can't reproduce this with gcc 4.1.2 on Fedora Core 6, x86.

[Martin Sebor]

Couldn't reproduce with gcc 3.2.3-56 (tried 15s and 15S) on Red Hat EL 3 (Taroon Update 8) but reproduced it in a 15D buiold with gcc 4.1.0 on SuSE 10.0.

Next time though, before chasing this down, look at STDCXX-435 first!

[Martin Sebor]

Disabled formatting and set Affects and Fix Version/s.

[Martin Sebor]

Fixed by resolving STDCXX-435.