[stlport-bugs] [ stlport-Bugs-2070991 ] Unit FstreamTest::tellp fails with VS 2008 SP1

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Bugs item #2070991, was opened at 2008-08-24 08:56
Message generated for change (Comment added) made by eckhardt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=2070991&group_id=146814

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General code
Group: None
Status: Open
Resolution: Duplicate
Priority: 1
Private: No
Submitted By: Alex Tartakovsky (tartak)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unit FstreamTest::tellp fails with VS 2008 SP1

Initial Comment:
STLport (trunk 3617) has built with MS VS 2008 SP1 just fine. All tests have passed, except one:

FstreamTest::tellp

../../../test/unit\fstream_test.cpp(295) : CPPUNIT_CHECK(o.rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out ) == ofstream::pos_type(9));

../../../test/unit\fstream_test.cpp(296) : CPPUNIT_CHECK(o.tellp() == ofstream::pos_type(9));

../../../test/unit\fstream_test.cpp(300) : CPPUNIT_CHECK(ftell( f ) == 9);

Any idea? Any relation to the previous report on tellp?

----------------------------------------------------------------------

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-25 13:03

Message:
Logged In: YES 
user_id=1522877
Originator: NO

To the question whether std::fstream should follow fopen() behaviour,
that's a clear yes, because the standard actually defines std::fstream
behaviour in terms of fopen() behaviour.

I don't know what you mean with "_but reference implementation isn't W._",
could you spell out what you really mean?

Now, as far as these tests are concerned, they actually test things that
are simply not guaranteed by any standard (C, C++ or POSIX). The point is
that the write position after opening with 'out|app' or "a" is simply not
guaranteed ("implementation defined"), but the tests check that it has a
certain value. Note that the requirement that writes happen at the end does
_NOT_ imply that the write position must be at the end after opening.

If this is still not clear to you Petr, I'm really afraid that this is due
to your bad understanding of the standard's language paired with a sincere
case of thickheadedness and arrogance on your side. Seriously, try to get
someone to translate those parts to you. I for one am tired of the endless
discussions we already suffered with you and your misunderstanding of how
std::string::find() should work, I don't need to repeat that.

Just think about it: doesn't it make you suspicious if several people
independently point out to you that you understanding something is wrong?
Has it ever occurred to you that the reason for that might be that your
understanding is simply wrong? Your refusal to admit a mistake is damaging
this project beyond your contributions and btw, your hijacking of it is
absolutely atrocious.

Uli

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-25 09:34

Message:
Logged In: YES 
user_id=615813
Originator: NO

Issue under discussion:

 - whether fstream behaviour should follow fopen implementation
 - or follow some unified behaviour.

Test follow first case, _but reference implementation isn't W._
In second case, if it happens, I don't want to follow
W. too --- I want to switch fstreams on *nixes from underlined unistd
implementation to stdio (better performance on modern *nixes), so behaviour
of fopen will be reference point again.

----------------------------------------------------------------------

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-25 09:03

Message:
Logged In: YES 
user_id=1522877
Originator: NO

The check is bogus, as you yourself proved with the references you
provided. As far as STLport use is concerned, I believe there is one
useless seek() after opening with 'app', other than that, it doesn't
exhibit any behaviour that should break programs.

Uli

----------------------------------------------------------------------

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-25 07:52

Message:
Logged In: YES 
user_id=1331880
Originator: YES

OK, I've read the discussion in
https://sourceforge.net/tracker/index.php?func=detail&aid=2001222&group_id=146814&atid=766244
and what the official C99 and C++ 2003 say. The standard says that "open"
in fstream should do as fopen does. In addition, if (mode & ios_base::ate)
!= 0, "open" should position the file at the end. So, with (app | out) in
the test, open should not explicitly position at the end, it must only do
what fopen does. And, for fopen, 7.19.3 in C99 says:
"If a file can support positioning requests (such as a disk file, as
opposed to a terminal), then a file position indicator associated with the
stream is positioned at the start (character number zero) of the file,
unless the file is opened with append mode in which case it is
implementation-defined whether the file position indicator is initially
positioned at the beginning or the end of the file."

So, fopen( , "a") is implementation specific and so must be open( , app |
out) in fstream. It really looks like the result of this test is supposed
by the standard to be implementation specific. What's the point of the test
then? MS implementation positions at the beginning (as their documentation
states) and they are within the standard. 

----------------------------------------------------------------------

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-24 17:08

Message:
Logged In: YES 
user_id=615813
Originator: NO

Test is correct. See references below.

References:

http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2008/n2691.pdf
(27.8.1.4);
http://www.opengroup.org/onlinepubs/7990989775/xsh/fopen.html;
http://www.opengroup.org/onlinepubs/7990989775/xsh/open.html

Issue under discussion: whether fstream behaviour should follow fopen
implementation (I oriented on POSIX, not on implementation from one
Redmond-based company), as specified in standard or assume some unified
behaviour.

You can suggest patch for platform-specific code that fix behaviour under
W.

See also
https://sourceforge.net/tracker/index.php?func=detail&aid=2001222&group_id=146814&atid=766244

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=766244&aid=2070991&group_id=146814