[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) 454-5900

Bugs item #2070991, was opened at 2008-08-24 10:56
Message generated for change (Comment added) made by complement
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: Petr Ovtchenkov (complement)
Date: 2008-08-25 23:08

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

Alex,

You can suggest patch. I expect something like

#ifndef WIN32
// current code
#else
// what expected under Wins
#endif

in fstream_test.cpp. 

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-25 21:17

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

Guys, it was not my intent to start (or reignite) a flame war. Nor do I
appreciate thinly veiled attempts to belittle Windows and MS implementation
of the standard libraries - such things are better left for kids. I may
share general disdain towards MS, but I have to work under Windows, in VS,
and I've come to depend on the excellent stlport too. 

As far as I can see, there is no problem with stlport's tellp per se.
tellp and pubseekoff follow fopen in my environment - just as the standards
require. In append mode, all three position at the beginning in my
environment, which is fine with the standards. The problem is with the
test: it checks something which is not defined by the standards. It
explicitly assumes the behavior of a particular implementation, without
checking for its presence or any warning. As is, this test just makes no
sense. Add a write operation after opening but before position checking -
and all three will point at the end. 

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

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

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

Answer one question:

What say 'ftell( f )' immediate after 'FILE* f = fopen( "test_file.txt",
"a" );' under Linux, MacOS X, FreeBSD, Solaris, HP-UX, well, and Windows
_operational environments_ (if you don't want to see words Operational
System here)?

Only this has sense in context of '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' (cite, see tartak's
post below).

'Implementation-dependence' come from explicit mentioned 'as fopen' in C++
standard and unspecified behaviour (in this issue) in POSIX.

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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-25 16:41

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

> Tests explicitly follow behaviour of fopen on POSIX-like platforms.

Looking at http://www.opengroup.org/onlinepubs/7990989775/xsh/fopen.html I
don't see anywhere that it's mentioned that after opening in append mode
the write position must be at the end. The write position isn't mentioned
at all, so the behaviour is implementation-defined. In fact, it doesn't
even make sense, because you have to perform the seek before any write
operation anyway and not just once after opening the file. Doing it already
after opening might be an optimisation.

> From [ 2070991 ] I see that implementation of fopen on Windows (or some
> versions of Windows) don't shift write pointer during
fopen("test_file.txt",
> "a" ) as POSIX-like platforms do.

Just FYI: MS Windows doesn't implement fopen() at all. Rather, it is
implementations of the C API running on top of MS Windows which implement
fopen(), so the behaviour isn't even specific to MS Windows.

> If fstream's behaviour will follow fopen, then test is
platform-specific,
> and #ifdef WIN required in test.

#ifdef _WIN32 would be wrong, for the above reasons that it is not the OS
that implements the actual calls. I'd suggest just checking for compliance
with the standard, i.e. that append mode works as required. I already
posted a suggestion that checks that calls to seekp() don't affect the
outcome in the last thread about the topic.

Optionally, I would check that the append mode for std::fstream works like
fopen(), but that has a low-priority for me because I can't imagine a sane
program that would actually depend on it.

Oh, and what words did I ascribe to you that you didn't say? The only time
I quoted you here was in a plea to clarify something, which btw has
remained unanswered, so there's now actually two things to clarify.

Uli

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-25 16:01

Message:
Logged In: YES 
user_id=615813
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.

Ok, I lean towards the same view.

Tests explicitly follow behaviour of fopen on POSIX-like platforms.
>From [ 2070991 ] I see that implementation of fopen on Windows (or some
versions of Windows) don't shift write pointer during fopen(
"test_file.txt", "a" ) as POSIX-like platforms do. It's clean enough, isn't
it?

If fstream's behaviour will follow fopen, then test is platform-specific,
and
#ifdef WIN required in test. You can suggest patch.

As about the rest, please, don't ascribe me words that I don't say.
Please, write here messages about this bug report only.

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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-25 15: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 11: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 11: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 09: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 19: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