stlport-bugs

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

[SourceForge.net <no...@so...>]

Bugs item #2070991, was opened at 2008-08-24 02:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
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: None
Priority: 5
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?



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

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

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

[SourceForge.net <no...@so...>]

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-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

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

[SourceForge.net <no...@so...>]

Bugs item #2070991, was opened at 2008-08-24 02:56
Message generated for change (Comment added) made by tartak
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: Alex Tartakovsky (tartak)
Date: 2008-08-25 01: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 11: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

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

[SourceForge.net <no...@so...>]

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 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

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

[SourceForge.net <no...@so...>]

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 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

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

[SourceForge.net <no...@so...>]

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

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

[SourceForge.net <no...@so...>]

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 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

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

[SourceForge.net <no...@so...>]

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 14: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 14: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 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

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

[SourceForge.net <no...@so...>]

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 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

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

[SourceForge.net <no...@so...>]

Bugs item #2070991, was opened at 2008-08-24 02:56
Message generated for change (Comment added) made by tartak
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: Alex Tartakovsky (tartak)
Date: 2008-08-25 13: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 09: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 08: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 08: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 07: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 03: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 03: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 01: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 11: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

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

[SourceForge.net <no...@so...>]

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

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

[SourceForge.net <no...@so...>]

Bugs item #2070991, was opened at 2008-08-24 02:56
Message generated for change (Comment added) made by tartak
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: Alex Tartakovsky (tartak)
Date: 2008-08-25 16:31

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

Petr,

I just don't understand why you insist on testing the way, which is not
defined by the standard. And, in any case, it's not about Windows, it's
about MS C libraries vs. lots of other libraries that can live in Windows.


Why not simply change the test in an implementation-independent way? For
example, add a write before tellp... So, add 'o << "X";' after 'ofstream o(
"test_file.txt", ios_base::app | ios_base::out );' and, of course, change 9
to 10 in the test. For reference fopen - just add 'fputs( "X", f );' after
'FILE* f = fopen( "test_file.txt", "a" );' and change 9 to 11. I guess this
would still test what you intended to test (tellp), so why not?

Alexei


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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-25 15: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 13: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 09: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 08: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 08: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 07: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 03: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 03: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 01: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 11: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

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

[SourceForge.net <no...@so...>]

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-26 09:40

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

> ... why you insist on testing the way, which is not
defined by the standard.

There was more then one question about this issue.
That's why test should give explicit answer on this question,
even if it demonstrate ambiguity. 'implementation-independent way'
don't give answer to original question and don't highlight problem.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 00:31

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

Petr,

I just don't understand why you insist on testing the way, which is not
defined by the standard. And, in any case, it's not about Windows, it's
about MS C libraries vs. lots of other libraries that can live in Windows.


Why not simply change the test in an implementation-independent way? For
example, add a write before tellp... So, add 'o << "X";' after 'ofstream o(
"test_file.txt", ios_base::app | ios_base::out );' and, of course, change 9
to 10 in the test. For reference fopen - just add 'fputs( "X", f );' after
'FILE* f = fopen( "test_file.txt", "a" );' and change 9 to 11. I guess this
would still test what you intended to test (tellp), so why not?

Alexei


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

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

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

[SourceForge.net <no...@so...>]

Bugs item #2070991, was opened at 2008-08-24 02:56
Message generated for change (Comment added) made by tartak
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: Alex Tartakovsky (tartak)
Date: 2008-08-27 12:30

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

OK, if you want an explicit position (which is implementation-dependent,
but is defined in each platform's documentation), then I propose simply
this change:

{
  #ifdef WIN32
  long expected_pos = 0;
  #else
  long expected_pos = 9;
  #endif
  ofstream o( "test_file.txt", ios_base::app | ios_base::out );
  CPPUNIT_CHECK( o.rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )
== ofstream::pos_type(expected_pos) );
  CPPUNIT_CHECK( o.tellp() == ofstream::pos_type(expected_pos) );
}
{ // for reference, to test just above:
  #ifdef WIN32
  long expected_pos = 0;
  #else
  long expected_pos = 9;
  #endif
  FILE* f = fopen( "test_file.txt", "a" );
  CPPUNIT_CHECK( ftell( f ) == expected_pos );
  fclose( f );
}

This explicitly tests for position.  Well, it assumes 2 known positions -
in Unix and Win32. For the 3rd possible underlying implementation - stdio
(neither Unix, nor Win32) - it goes with Unix, which may not be correct. 

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-27 04:56

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

Please, write here messages about _this bug report only_, that has
_technical meaning_.

Use another place for throw conniptions or have out with me.

Message "You try to modify question to get convenient answer. ..." was
answer for tartak's "After going deep into the source code, ...".


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-27 03:35

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

Petr Ovtchenkov, that you of all are accusing someone of twisting a
question to get a convenient answer is pure irony. Aren't you the one that
is not answering straight questions? Aren't you the one that's been falsely
claiming that I misrepresented him but is neither able to back up that
claim nor redrawing that claim? And now again, you mention an "original
question", without giving the slightest hint which that question might have
been, a misunderstanding of the standard leading to unexpected behaviour, a
test case reporting a false positive, or maybe which test is useful? Well,
since you are once more not being explicit about what you mean, it is
impossible for anyone to discuss that unknown moving target that exists
only in your mind. That's also a way to "win" (actually, you lose) an
argument, well done Petr Ovtchenkov. Combined with you hijacking the
STLport project I'm seriously wondering where this project is going,
probably down, since you alone can't manage it and your way of mistreating
people will scare off any potential contributor, as has happened in the
past numerous times.


> Original test I wrote, give answer in constructive form: 'yes,
> sometimes you can take file size with such code, but only on
> some platforms; for this platform it work, for that it not
> work; you has basis for decision: whether to use this
> technique'.

Well, the technique to determine the file size is not portable, neither in
reality nor according to the relevant standards.

> This information is really useful for me.

Ah, and because it is useful to Petr Ovtchenkov means that everyone must
consider it useful? No, it doesn't, to most people who only want to write
portable code and use a working C++ stdlib this information is absolutely
irrelevant. But well, I'm just ranting, I have already given up on you
getting some sense.



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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-27 02:35

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

You try to modify question to get convenient answer. Original question
come from attempt to take file size (I suspect this, I don't use such code
in my practice ;-). Original test I wrote, give answer in constructive
form: 'yes, sometimes you can take file size with such code, but only on
some platforms; for this platform it work, for that it not work; you has
basis for decision: whether to use this technique'. This information is
really useful for me.

The fact, that Windows fstream implementation don't use stdio has no
importance. [Linux implementation of fstreams also don't use stdio now].
But because code is compilable and linkable, I know that fopen is present
under you operational environment too. And it may be used for reference,
because standard refer to fopen's behaviour.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 14:38

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

Petr,
After going deep into the source code, I think I can see now your point
about ambiguity. I was clearly wrong about what constitutes the environment
in my case. I thought it was the C library, but now I agree that in STLport
- it's Windows.
Ultimately,pubseekoff calls _Filebuf_base::_M_seek, which calls on of the
three implementations:
1) Unix (defined (_STLP_USE_UNIX_IO) || defined
(_STLP_USE_UNIX_EMULATION_IO))
lseek
2) STDIO (defined (_STLP_USE_STDIO_IO)) - applies only to Apple, as far as
I can see
fseek
3) Windows (defined (_STLP_USE_WIN32_IO), the same as _STLP_WIN32, always
defined in WIn32)
SetFilePointer

So, while the standard stipulates that open/pubseekoff behave as
fopen/ftell, this depends on how fopen behaves, which is beyond stlport. Of
course, in WIn32, ftell would likely have no choice but call Win32 API's
SetFilePointer, but the ambiguity does exist. 

At any rate, trying to be constructive, I already proposed the patch to
test whether the append mode writes to the end. And, as I explained
already, to test your question - whether pubseekoff immediately after open
and ftell after fopen behave the same in append mode - the existing test
should be changed to something like:
{
  FILE* f = fopen( "test_file.txt", "a" );
  long pos = ftell( f );
  fclose( f );
  ofstream o( "test_file.txt", ios_base::app | ios_base::out );
  CPPUNIT_CHECK( o.tellp() == ofstream::pos_type(pos) );
}

So, we can have two tests. And Uli mentioned one more. 
I think, it's pretty constructive. 

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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 07:12

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

Quoting Petr Ovtchenkov from commit r3618, concerning the write position
after opening in append mode: "It isn't specifications violation, neither
for Linux and Mac OS X nor for Windows."

Now, was that so difficult? That is exactly what people have been telling
you all over and which you were refusing to see or admit the whole time.
And here you finally admit that the test is meaningless if you want to
check whether STLport works correctly or not. I have serious problem
understanding how a human being can at the same time be a brilliant
technician and at the same time be so incredibly stubborn to see that they
made a mistake.

Now, the only thing left to do is to make changes to the code so that it
doesn't create bogus test failures. Oh, btw, just excluding win32 from that
is wrong too, because (guess what!) artefacts from different implementation
like those that you are still testing there are far from guaranteed.
Nothing guarantees that they will not change in a future version of this or
that platform. So, for the sake of portability, remove this whole goddamn
test. It's broken beyond repair.

Instead, there have been two other tests proposed that actually do make
sense and that both make sure the handling of the append mode is correct.
One was to check that writes after opening actually happen at the end and
the other is that seekp() calls in between don't affect the write
position.


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 05:33

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

> Test give me answer. I give suggestion to you, how
> to give better and explicit answer.

But what answer? It only tests if the implementation-specific behaviour
conforms to that which you observed on a few platform. It fails on other
platforms, which have a different (equally correct) behaviour. Since the
failure of this test depends on implementation-defined behaviour, the test
is meaningless to those people that are interested in correct STLport
behaviour. Note that last part of the sentence, it might be that the test
has some meaning to you (I have no idea what meaning that is and basically
don't care), but that is irrelevant to STLport.


> Because I don't see constructive things in last messages,
> I stop posting on this issue.

What? Is that the way you solve technical discussions? That's extremely
poor. Oh, and concerning the constructiveness of these messages, I asked
you quite some very easy and explicit questions. How about you finally live
up to your own twisted standards and answer those?

Uli


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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 04:00

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

> Petr, you ought to admit that the test does not fit with the
question/answer you've posted.

Test give me answer. I give suggestion to you, how to give better and
explicit answer.

Because I don't see constructive things in last messages, I stop posting
on this issue.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 03:18

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

>> The test doesn't answer any questions         
>             
>Really? It answer a lot of questions for me. One answer is expressed in
>test.             
>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_?'             
>             
>The answer should be same as for question       
>             
>'What say 'rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )'
>immediate after 'ofstream o( "test_file.txt", ios_base::app |
ios_base::out
>);'?             
>             
>under same operational environment.             

Finally, we have both a question and the answer that the test was supposed
to give. The problem is, the test does not answer this question at all. To
check that both positions are the same, we should store the position
returned by ftell after fopen and compare it with the position returned by
tellp/pubseekoff in the same situation. Instead, the test just compares
both positions with the end of the file, but not with each other. 

Petr, you ought to admit that the test does not fit with the
question/answer you've posted.

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 03:00

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

> But what is the problem? What is the original question?

> all I can guess now is that you are referring to some other question
which
only you know.

[ 2001222 ], [ 2070991 ], and, IRC, a few similar questions year or two
ago.

> The test doesn't answer any questions

Really? It answer a lot of questions for me. One answer is expressed in
test.
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_?'

The answer should be same as for question

'What say 'rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )'
immediate after 'ofstream o( "test_file.txt", ios_base::app | ios_base::out
);'?

under same operational environment.

As the rest, if you want to have out with me, then bug report isn't
correct place for this.

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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 02:34

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

Sorry, last sentence was erroneously quoted.


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 02:33

Message:
Logged In: YES 
user_id=1522877
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)?

AFAIK, on some it gives you a position at the end of the file, on others
it gives you one at the beginning. I haven't tested this myself though, I
have to trust others who presumably did.


Now, would you also answer a question?

> 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).

What is the 'this' that you are referring to? The only thing that you
wrote before that is a question and assuming that that is what 'this'
refers to, this makes no sense at all. So, I guess you meant something
different than what you wrote. Again, please explain more clearly what you
mean, so that people are actually able to understand you. Maybe you need
someone to proofread the stuff for you, so get someone to do it, but those
ambiguous statements are simply detrimental to discussions.

BTW: who cares what the position after opening is?


'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-26 02:24

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

Petr, please be so kind and be a bit more verbose. Why? Let's see, your
last posting here:

>> ... why you insist on testing the way, which is
>> not defined by the standard.
> 
> There was more then one question about this issue.

Right, but there is only one question left, and that is the correct
position after fopen(..,"a") or fstream equivalent.

> That's why test should give explicit answer on this question,
> even if it demonstrate ambiguity.

The test doesn't answer any questions but asserts a certain behaviour. So,
all I can guess now is that you are referring to some other question which
only you know. 

> 'implementation-independent way' don't give answer to
> original question and don't highlight problem.

So? The proposed test just checks that append mode behaves as required,
i.e. always writes to the end. It might seem like a separate issue but it's
the only meaningful test. Testing the write position after opening just
isn't.


Further, Petr, I'm still waiting for you to either publicly state where I
misrepresented you or to redraw that claim and write an excuse. I don't
like being called a liar, which is effectively what you were doing.


Uli


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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 02:14

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

But what is the problem? What is the original question? It's hard to see
any left. The only way to give an explicit answer on what is unspecified in
the standard is to change the standard. 

I posted the report because this test failed in my environment. Now, after
this discussion, I can clearly see that there is no problem with stlport
here. The only problem is with the test itself. 

If the goal is to highlight all implementation-dependent things mentioned
in the standard, I bet many more tests could be added, just like this one.
The likely result will be simply a lot of frustration and bogus bug reports
here. And a loss of credibility for the whole test suite.

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 01:40

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

> ... why you insist on testing the way, which is not
defined by the standard.

There was more then one question about this issue.
That's why test should give explicit answer on this question,
even if it demonstrate ambiguity. 'implementation-independent way'
don't give answer to original question and don't highlight problem.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-25 16:31

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

Petr,

I just don't understand why you insist on testing the way, which is not
defined by the standard. And, in any case, it's not about Windows, it's
about MS C libraries vs. lots of other libraries that can live in Windows.


Why not simply change the test in an implementation-independent way? For
example, add a write before tellp... So, add 'o << "X";' after 'ofstream o(
"test_file.txt", ios_base::app | ios_base::out );' and, of course, change 9
to 10 in the test. For reference fopen - just add 'fputs( "X", f );' after
'FILE* f = fopen( "test_file.txt", "a" );' and change 9 to 11. I guess this
would still test what you intended to test (tellp), so why not?

Alexei


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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-25 15: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 13: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 09: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 08: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 08: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 07: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 03: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 03: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 01: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 11: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

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

[SourceForge.net <no...@so...>]

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-27 22:54

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

<snip>... then I propose simply this change:
<snip>

Yes, this is what I want to see here. Attach here (see bottom of this web
page) normal patch (against source tree, i.e. _normal_ patch).


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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-27 20:30

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

OK, if you want an explicit position (which is implementation-dependent,
but is defined in each platform's documentation), then I propose simply
this change:

{
  #ifdef WIN32
  long expected_pos = 0;
  #else
  long expected_pos = 9;
  #endif
  ofstream o( "test_file.txt", ios_base::app | ios_base::out );
  CPPUNIT_CHECK( o.rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )
== ofstream::pos_type(expected_pos) );
  CPPUNIT_CHECK( o.tellp() == ofstream::pos_type(expected_pos) );
}
{ // for reference, to test just above:
  #ifdef WIN32
  long expected_pos = 0;
  #else
  long expected_pos = 9;
  #endif
  FILE* f = fopen( "test_file.txt", "a" );
  CPPUNIT_CHECK( ftell( f ) == expected_pos );
  fclose( f );
}

This explicitly tests for position.  Well, it assumes 2 known positions -
in Unix and Win32. For the 3rd possible underlying implementation - stdio
(neither Unix, nor Win32) - it goes with Unix, which may not be correct. 

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-27 12:56

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

Please, write here messages about _this bug report only_, that has
_technical meaning_.

Use another place for throw conniptions or have out with me.

Message "You try to modify question to get convenient answer. ..." was
answer for tartak's "After going deep into the source code, ...".


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-27 11:35

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

Petr Ovtchenkov, that you of all are accusing someone of twisting a
question to get a convenient answer is pure irony. Aren't you the one that
is not answering straight questions? Aren't you the one that's been falsely
claiming that I misrepresented him but is neither able to back up that
claim nor redrawing that claim? And now again, you mention an "original
question", without giving the slightest hint which that question might have
been, a misunderstanding of the standard leading to unexpected behaviour, a
test case reporting a false positive, or maybe which test is useful? Well,
since you are once more not being explicit about what you mean, it is
impossible for anyone to discuss that unknown moving target that exists
only in your mind. That's also a way to "win" (actually, you lose) an
argument, well done Petr Ovtchenkov. Combined with you hijacking the
STLport project I'm seriously wondering where this project is going,
probably down, since you alone can't manage it and your way of mistreating
people will scare off any potential contributor, as has happened in the
past numerous times.


> Original test I wrote, give answer in constructive form: 'yes,
> sometimes you can take file size with such code, but only on
> some platforms; for this platform it work, for that it not
> work; you has basis for decision: whether to use this
> technique'.

Well, the technique to determine the file size is not portable, neither in
reality nor according to the relevant standards.

> This information is really useful for me.

Ah, and because it is useful to Petr Ovtchenkov means that everyone must
consider it useful? No, it doesn't, to most people who only want to write
portable code and use a working C++ stdlib this information is absolutely
irrelevant. But well, I'm just ranting, I have already given up on you
getting some sense.



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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-27 10:35

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

You try to modify question to get convenient answer. Original question
come from attempt to take file size (I suspect this, I don't use such code
in my practice ;-). Original test I wrote, give answer in constructive
form: 'yes, sometimes you can take file size with such code, but only on
some platforms; for this platform it work, for that it not work; you has
basis for decision: whether to use this technique'. This information is
really useful for me.

The fact, that Windows fstream implementation don't use stdio has no
importance. [Linux implementation of fstreams also don't use stdio now].
But because code is compilable and linkable, I know that fopen is present
under you operational environment too. And it may be used for reference,
because standard refer to fopen's behaviour.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 22:38

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

Petr,
After going deep into the source code, I think I can see now your point
about ambiguity. I was clearly wrong about what constitutes the environment
in my case. I thought it was the C library, but now I agree that in STLport
- it's Windows.
Ultimately,pubseekoff calls _Filebuf_base::_M_seek, which calls on of the
three implementations:
1) Unix (defined (_STLP_USE_UNIX_IO) || defined
(_STLP_USE_UNIX_EMULATION_IO))
lseek
2) STDIO (defined (_STLP_USE_STDIO_IO)) - applies only to Apple, as far as
I can see
fseek
3) Windows (defined (_STLP_USE_WIN32_IO), the same as _STLP_WIN32, always
defined in WIn32)
SetFilePointer

So, while the standard stipulates that open/pubseekoff behave as
fopen/ftell, this depends on how fopen behaves, which is beyond stlport. Of
course, in WIn32, ftell would likely have no choice but call Win32 API's
SetFilePointer, but the ambiguity does exist. 

At any rate, trying to be constructive, I already proposed the patch to
test whether the append mode writes to the end. And, as I explained
already, to test your question - whether pubseekoff immediately after open
and ftell after fopen behave the same in append mode - the existing test
should be changed to something like:
{
  FILE* f = fopen( "test_file.txt", "a" );
  long pos = ftell( f );
  fclose( f );
  ofstream o( "test_file.txt", ios_base::app | ios_base::out );
  CPPUNIT_CHECK( o.tellp() == ofstream::pos_type(pos) );
}

So, we can have two tests. And Uli mentioned one more. 
I think, it's pretty constructive. 

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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 15:12

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

Quoting Petr Ovtchenkov from commit r3618, concerning the write position
after opening in append mode: "It isn't specifications violation, neither
for Linux and Mac OS X nor for Windows."

Now, was that so difficult? That is exactly what people have been telling
you all over and which you were refusing to see or admit the whole time.
And here you finally admit that the test is meaningless if you want to
check whether STLport works correctly or not. I have serious problem
understanding how a human being can at the same time be a brilliant
technician and at the same time be so incredibly stubborn to see that they
made a mistake.

Now, the only thing left to do is to make changes to the code so that it
doesn't create bogus test failures. Oh, btw, just excluding win32 from that
is wrong too, because (guess what!) artefacts from different implementation
like those that you are still testing there are far from guaranteed.
Nothing guarantees that they will not change in a future version of this or
that platform. So, for the sake of portability, remove this whole goddamn
test. It's broken beyond repair.

Instead, there have been two other tests proposed that actually do make
sense and that both make sure the handling of the append mode is correct.
One was to check that writes after opening actually happen at the end and
the other is that seekp() calls in between don't affect the write
position.


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 13:33

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

> Test give me answer. I give suggestion to you, how
> to give better and explicit answer.

But what answer? It only tests if the implementation-specific behaviour
conforms to that which you observed on a few platform. It fails on other
platforms, which have a different (equally correct) behaviour. Since the
failure of this test depends on implementation-defined behaviour, the test
is meaningless to those people that are interested in correct STLport
behaviour. Note that last part of the sentence, it might be that the test
has some meaning to you (I have no idea what meaning that is and basically
don't care), but that is irrelevant to STLport.


> Because I don't see constructive things in last messages,
> I stop posting on this issue.

What? Is that the way you solve technical discussions? That's extremely
poor. Oh, and concerning the constructiveness of these messages, I asked
you quite some very easy and explicit questions. How about you finally live
up to your own twisted standards and answer those?

Uli


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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 12:00

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

> Petr, you ought to admit that the test does not fit with the
question/answer you've posted.

Test give me answer. I give suggestion to you, how to give better and
explicit answer.

Because I don't see constructive things in last messages, I stop posting
on this issue.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 11:18

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

>> The test doesn't answer any questions         
>             
>Really? It answer a lot of questions for me. One answer is expressed in
>test.             
>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_?'             
>             
>The answer should be same as for question       
>             
>'What say 'rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )'
>immediate after 'ofstream o( "test_file.txt", ios_base::app |
ios_base::out
>);'?             
>             
>under same operational environment.             

Finally, we have both a question and the answer that the test was supposed
to give. The problem is, the test does not answer this question at all. To
check that both positions are the same, we should store the position
returned by ftell after fopen and compare it with the position returned by
tellp/pubseekoff in the same situation. Instead, the test just compares
both positions with the end of the file, but not with each other. 

Petr, you ought to admit that the test does not fit with the
question/answer you've posted.

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 11:00

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

> But what is the problem? What is the original question?

> all I can guess now is that you are referring to some other question
which
only you know.

[ 2001222 ], [ 2070991 ], and, IRC, a few similar questions year or two
ago.

> The test doesn't answer any questions

Really? It answer a lot of questions for me. One answer is expressed in
test.
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_?'

The answer should be same as for question

'What say 'rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )'
immediate after 'ofstream o( "test_file.txt", ios_base::app | ios_base::out
);'?

under same operational environment.

As the rest, if you want to have out with me, then bug report isn't
correct place for this.

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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 10:34

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

Sorry, last sentence was erroneously quoted.


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 10:33

Message:
Logged In: YES 
user_id=1522877
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)?

AFAIK, on some it gives you a position at the end of the file, on others
it gives you one at the beginning. I haven't tested this myself though, I
have to trust others who presumably did.


Now, would you also answer a question?

> 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).

What is the 'this' that you are referring to? The only thing that you
wrote before that is a question and assuming that that is what 'this'
refers to, this makes no sense at all. So, I guess you meant something
different than what you wrote. Again, please explain more clearly what you
mean, so that people are actually able to understand you. Maybe you need
someone to proofread the stuff for you, so get someone to do it, but those
ambiguous statements are simply detrimental to discussions.

BTW: who cares what the position after opening is?


'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-26 10:24

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

Petr, please be so kind and be a bit more verbose. Why? Let's see, your
last posting here:

>> ... why you insist on testing the way, which is
>> not defined by the standard.
> 
> There was more then one question about this issue.

Right, but there is only one question left, and that is the correct
position after fopen(..,"a") or fstream equivalent.

> That's why test should give explicit answer on this question,
> even if it demonstrate ambiguity.

The test doesn't answer any questions but asserts a certain behaviour. So,
all I can guess now is that you are referring to some other question which
only you know. 

> 'implementation-independent way' don't give answer to
> original question and don't highlight problem.

So? The proposed test just checks that append mode behaves as required,
i.e. always writes to the end. It might seem like a separate issue but it's
the only meaningful test. Testing the write position after opening just
isn't.


Further, Petr, I'm still waiting for you to either publicly state where I
misrepresented you or to redraw that claim and write an excuse. I don't
like being called a liar, which is effectively what you were doing.


Uli


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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 10:14

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

But what is the problem? What is the original question? It's hard to see
any left. The only way to give an explicit answer on what is unspecified in
the standard is to change the standard. 

I posted the report because this test failed in my environment. Now, after
this discussion, I can clearly see that there is no problem with stlport
here. The only problem is with the test itself. 

If the goal is to highlight all implementation-dependent things mentioned
in the standard, I bet many more tests could be added, just like this one.
The likely result will be simply a lot of frustration and bogus bug reports
here. And a loss of credibility for the whole test suite.

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 09:40

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

> ... why you insist on testing the way, which is not
defined by the standard.

There was more then one question about this issue.
That's why test should give explicit answer on this question,
even if it demonstrate ambiguity. 'implementation-independent way'
don't give answer to original question and don't highlight problem.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 00:31

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

Petr,

I just don't understand why you insist on testing the way, which is not
defined by the standard. And, in any case, it's not about Windows, it's
about MS C libraries vs. lots of other libraries that can live in Windows.


Why not simply change the test in an implementation-independent way? For
example, add a write before tellp... So, add 'o << "X";' after 'ofstream o(
"test_file.txt", ios_base::app | ios_base::out );' and, of course, change 9
to 10 in the test. For reference fopen - just add 'fputs( "X", f );' after
'FILE* f = fopen( "test_file.txt", "a" );' and change 9 to 11. I guess this
would still test what you intended to test (tellp), so why not?

Alexei


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

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

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

[SourceForge.net <no...@so...>]

Bugs item #2070991, was opened at 2008-08-24 02:56
Message generated for change (Comment added) made by tartak
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: Alex Tartakovsky (tartak)
Date: 2008-08-27 21:12

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

Patch is attached. Added support for Windows in FstreamTest::tellp(). The
problem is not specific to MSVS. 

Francois, I did not know that one of the test modifications I proposed a
few posts below was in place already in rev 3611. Too bad, looks like Petr
is very much against it.

I hope you were joking about turning your back on Windows users.  I depend
very much on stlport and boost. If stlport declares any MSVS implementation
"strange" and drops its support, boost people will be forced to drop
support for stlport too. They list MSVS 7.1, 8 and 9 as fully supported.
Hopefully, the definition of "strange" will mean a major deviation from the
standard, rather than someone's disdain for all things MS.

Alexei
File Added: fstream_test.diff

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

Comment By: Francois Dumont (dums)
Date: 2008-08-27 16:27

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

  Alex, if you want a patch you can take a look to fstream_test.cpp in
trunk on revision 3611. It more than a month old now, what a waste of time
!

  Considering this discussion thread and the announcement 'STLport source
control/goal', it looks like Windows users will have to find an other
Standard lib implementation !

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-27 14:54

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

<snip>... then I propose simply this change:
<snip>

Yes, this is what I want to see here. Attach here (see bottom of this web
page) normal patch (against source tree, i.e. _normal_ patch).


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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-27 12:30

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

OK, if you want an explicit position (which is implementation-dependent,
but is defined in each platform's documentation), then I propose simply
this change:

{
  #ifdef WIN32
  long expected_pos = 0;
  #else
  long expected_pos = 9;
  #endif
  ofstream o( "test_file.txt", ios_base::app | ios_base::out );
  CPPUNIT_CHECK( o.rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )
== ofstream::pos_type(expected_pos) );
  CPPUNIT_CHECK( o.tellp() == ofstream::pos_type(expected_pos) );
}
{ // for reference, to test just above:
  #ifdef WIN32
  long expected_pos = 0;
  #else
  long expected_pos = 9;
  #endif
  FILE* f = fopen( "test_file.txt", "a" );
  CPPUNIT_CHECK( ftell( f ) == expected_pos );
  fclose( f );
}

This explicitly tests for position.  Well, it assumes 2 known positions -
in Unix and Win32. For the 3rd possible underlying implementation - stdio
(neither Unix, nor Win32) - it goes with Unix, which may not be correct. 

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-27 04:56

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

Please, write here messages about _this bug report only_, that has
_technical meaning_.

Use another place for throw conniptions or have out with me.

Message "You try to modify question to get convenient answer. ..." was
answer for tartak's "After going deep into the source code, ...".


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-27 03:35

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

Petr Ovtchenkov, that you of all are accusing someone of twisting a
question to get a convenient answer is pure irony. Aren't you the one that
is not answering straight questions? Aren't you the one that's been falsely
claiming that I misrepresented him but is neither able to back up that
claim nor redrawing that claim? And now again, you mention an "original
question", without giving the slightest hint which that question might have
been, a misunderstanding of the standard leading to unexpected behaviour, a
test case reporting a false positive, or maybe which test is useful? Well,
since you are once more not being explicit about what you mean, it is
impossible for anyone to discuss that unknown moving target that exists
only in your mind. That's also a way to "win" (actually, you lose) an
argument, well done Petr Ovtchenkov. Combined with you hijacking the
STLport project I'm seriously wondering where this project is going,
probably down, since you alone can't manage it and your way of mistreating
people will scare off any potential contributor, as has happened in the
past numerous times.


> Original test I wrote, give answer in constructive form: 'yes,
> sometimes you can take file size with such code, but only on
> some platforms; for this platform it work, for that it not
> work; you has basis for decision: whether to use this
> technique'.

Well, the technique to determine the file size is not portable, neither in
reality nor according to the relevant standards.

> This information is really useful for me.

Ah, and because it is useful to Petr Ovtchenkov means that everyone must
consider it useful? No, it doesn't, to most people who only want to write
portable code and use a working C++ stdlib this information is absolutely
irrelevant. But well, I'm just ranting, I have already given up on you
getting some sense.



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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-27 02:35

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

You try to modify question to get convenient answer. Original question
come from attempt to take file size (I suspect this, I don't use such code
in my practice ;-). Original test I wrote, give answer in constructive
form: 'yes, sometimes you can take file size with such code, but only on
some platforms; for this platform it work, for that it not work; you has
basis for decision: whether to use this technique'. This information is
really useful for me.

The fact, that Windows fstream implementation don't use stdio has no
importance. [Linux implementation of fstreams also don't use stdio now].
But because code is compilable and linkable, I know that fopen is present
under you operational environment too. And it may be used for reference,
because standard refer to fopen's behaviour.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 14:38

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

Petr,
After going deep into the source code, I think I can see now your point
about ambiguity. I was clearly wrong about what constitutes the environment
in my case. I thought it was the C library, but now I agree that in STLport
- it's Windows.
Ultimately,pubseekoff calls _Filebuf_base::_M_seek, which calls on of the
three implementations:
1) Unix (defined (_STLP_USE_UNIX_IO) || defined
(_STLP_USE_UNIX_EMULATION_IO))
lseek
2) STDIO (defined (_STLP_USE_STDIO_IO)) - applies only to Apple, as far as
I can see
fseek
3) Windows (defined (_STLP_USE_WIN32_IO), the same as _STLP_WIN32, always
defined in WIn32)
SetFilePointer

So, while the standard stipulates that open/pubseekoff behave as
fopen/ftell, this depends on how fopen behaves, which is beyond stlport. Of
course, in WIn32, ftell would likely have no choice but call Win32 API's
SetFilePointer, but the ambiguity does exist. 

At any rate, trying to be constructive, I already proposed the patch to
test whether the append mode writes to the end. And, as I explained
already, to test your question - whether pubseekoff immediately after open
and ftell after fopen behave the same in append mode - the existing test
should be changed to something like:
{
  FILE* f = fopen( "test_file.txt", "a" );
  long pos = ftell( f );
  fclose( f );
  ofstream o( "test_file.txt", ios_base::app | ios_base::out );
  CPPUNIT_CHECK( o.tellp() == ofstream::pos_type(pos) );
}

So, we can have two tests. And Uli mentioned one more. 
I think, it's pretty constructive. 

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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 07:12

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

Quoting Petr Ovtchenkov from commit r3618, concerning the write position
after opening in append mode: "It isn't specifications violation, neither
for Linux and Mac OS X nor for Windows."

Now, was that so difficult? That is exactly what people have been telling
you all over and which you were refusing to see or admit the whole time.
And here you finally admit that the test is meaningless if you want to
check whether STLport works correctly or not. I have serious problem
understanding how a human being can at the same time be a brilliant
technician and at the same time be so incredibly stubborn to see that they
made a mistake.

Now, the only thing left to do is to make changes to the code so that it
doesn't create bogus test failures. Oh, btw, just excluding win32 from that
is wrong too, because (guess what!) artefacts from different implementation
like those that you are still testing there are far from guaranteed.
Nothing guarantees that they will not change in a future version of this or
that platform. So, for the sake of portability, remove this whole goddamn
test. It's broken beyond repair.

Instead, there have been two other tests proposed that actually do make
sense and that both make sure the handling of the append mode is correct.
One was to check that writes after opening actually happen at the end and
the other is that seekp() calls in between don't affect the write
position.


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 05:33

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

> Test give me answer. I give suggestion to you, how
> to give better and explicit answer.

But what answer? It only tests if the implementation-specific behaviour
conforms to that which you observed on a few platform. It fails on other
platforms, which have a different (equally correct) behaviour. Since the
failure of this test depends on implementation-defined behaviour, the test
is meaningless to those people that are interested in correct STLport
behaviour. Note that last part of the sentence, it might be that the test
has some meaning to you (I have no idea what meaning that is and basically
don't care), but that is irrelevant to STLport.


> Because I don't see constructive things in last messages,
> I stop posting on this issue.

What? Is that the way you solve technical discussions? That's extremely
poor. Oh, and concerning the constructiveness of these messages, I asked
you quite some very easy and explicit questions. How about you finally live
up to your own twisted standards and answer those?

Uli


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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 04:00

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

> Petr, you ought to admit that the test does not fit with the
question/answer you've posted.

Test give me answer. I give suggestion to you, how to give better and
explicit answer.

Because I don't see constructive things in last messages, I stop posting
on this issue.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 03:18

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

>> The test doesn't answer any questions         
>             
>Really? It answer a lot of questions for me. One answer is expressed in
>test.             
>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_?'             
>             
>The answer should be same as for question       
>             
>'What say 'rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )'
>immediate after 'ofstream o( "test_file.txt", ios_base::app |
ios_base::out
>);'?             
>             
>under same operational environment.             

Finally, we have both a question and the answer that the test was supposed
to give. The problem is, the test does not answer this question at all. To
check that both positions are the same, we should store the position
returned by ftell after fopen and compare it with the position returned by
tellp/pubseekoff in the same situation. Instead, the test just compares
both positions with the end of the file, but not with each other. 

Petr, you ought to admit that the test does not fit with the
question/answer you've posted.

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 03:00

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

> But what is the problem? What is the original question?

> all I can guess now is that you are referring to some other question
which
only you know.

[ 2001222 ], [ 2070991 ], and, IRC, a few similar questions year or two
ago.

> The test doesn't answer any questions

Really? It answer a lot of questions for me. One answer is expressed in
test.
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_?'

The answer should be same as for question

'What say 'rdbuf()->pubseekoff( 0, ios_base::cur, ios_base::out )'
immediate after 'ofstream o( "test_file.txt", ios_base::app | ios_base::out
);'?

under same operational environment.

As the rest, if you want to have out with me, then bug report isn't
correct place for this.

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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 02:34

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

Sorry, last sentence was erroneously quoted.


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

Comment By: Ulrich Eckhardt (eckhardt)
Date: 2008-08-26 02:33

Message:
Logged In: YES 
user_id=1522877
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)?

AFAIK, on some it gives you a position at the end of the file, on others
it gives you one at the beginning. I haven't tested this myself though, I
have to trust others who presumably did.


Now, would you also answer a question?

> 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).

What is the 'this' that you are referring to? The only thing that you
wrote before that is a question and assuming that that is what 'this'
refers to, this makes no sense at all. So, I guess you meant something
different than what you wrote. Again, please explain more clearly what you
mean, so that people are actually able to understand you. Maybe you need
someone to proofread the stuff for you, so get someone to do it, but those
ambiguous statements are simply detrimental to discussions.

BTW: who cares what the position after opening is?


'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-26 02:24

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

Petr, please be so kind and be a bit more verbose. Why? Let's see, your
last posting here:

>> ... why you insist on testing the way, which is
>> not defined by the standard.
> 
> There was more then one question about this issue.

Right, but there is only one question left, and that is the correct
position after fopen(..,"a") or fstream equivalent.

> That's why test should give explicit answer on this question,
> even if it demonstrate ambiguity.

The test doesn't answer any questions but asserts a certain behaviour. So,
all I can guess now is that you are referring to some other question which
only you know. 

> 'implementation-independent way' don't give answer to
> original question and don't highlight problem.

So? The proposed test just checks that append mode behaves as required,
i.e. always writes to the end. It might seem like a separate issue but it's
the only meaningful test. Testing the write position after opening just
isn't.


Further, Petr, I'm still waiting for you to either publicly state where I
misrepresented you or to redraw that claim and write an excuse. I don't
like being called a liar, which is effectively what you were doing.


Uli


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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-26 02:14

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

But what is the problem? What is the original question? It's hard to see
any left. The only way to give an explicit answer on what is unspecified in
the standard is to change the standard. 

I posted the report because this test failed in my environment. Now, after
this discussion, I can clearly see that there is no problem with stlport
here. The only problem is with the test itself. 

If the goal is to highlight all implementation-dependent things mentioned
in the standard, I bet many more tests could be added, just like this one.
The likely result will be simply a lot of frustration and bogus bug reports
here. And a loss of credibility for the whole test suite.

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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-26 01:40

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

> ... why you insist on testing the way, which is not
defined by the standard.

There was more then one question about this issue.
That's why test should give explicit answer on this question,
even if it demonstrate ambiguity. 'implementation-independent way'
don't give answer to original question and don't highlight problem.

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

Comment By: Alex Tartakovsky (tartak)
Date: 2008-08-25 16:31

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

Petr,

I just don't understand why you insist on testing the way, which is not
defined by the standard. And, in any case, it's not about Windows, it's
about MS C libraries vs. lots of other libraries that can live in Windows.


Why not simply change the test in an implementation-independent way? For
example, add a write before tellp... So, add 'o << "X";' after 'ofstream o(
"test_file.txt", ios_base::app | ios_base::out );' and, of course, change 9
to 10 in the test. For reference fopen - just add 'fputs( "X", f );' after
'FILE* f = fopen( "test_file.txt", "a" );' and change 9 to 11. I guess this
would still test what you intended to test (tellp), so why not?

Alexei


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

Comment By: Petr Ovtchenkov (complement)
Date: 2008-08-25 15: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 13: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 09: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 08: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 08: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 07: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 03: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 03: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 01: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 11: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