stlport-bugs Mailing List for STLport
Brought to you by:
complement
Menu
▾
▴
stlport-bugs — STLport bugs tracking mailing list
You can subscribe to this list here.
| 2007 |
Jan
(24) |
Feb
(38) |
Mar
(45) |
Apr
(13) |
May
(43) |
Jun
(2) |
Jul
(9) |
Aug
(13) |
Sep
(35) |
Oct
(12) |
Nov
(24) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(29) |
Feb
(5) |
Mar
(26) |
Apr
(12) |
May
(13) |
Jun
(15) |
Jul
(8) |
Aug
(20) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Petr O. <pt...@vo...> - 2013-06-03 18:34:54
|
Good day, On Mon, 3 Jun 2013 18:08:39 +0800 Chenyang <du...@gm...> wrote: > Hi Ptr, > 1. For long long type issue. > Below additional check with yellow background can be added into function > __get_integer() to fix the *long long* type corner case. It would be better if you send _normal_ patch (patchset) against STLport-5.2 (right?) branch. With best regards, -- - ptr |
|
From: Chenyang <du...@gm...> - 2013-06-03 10:08:46
|
Hi Ptr,
1. For long long type issue.
Below additional check with yellow background can be added into function
__get_integer() to fix the *long long* type corner case.
Refer to file: stlport/stlport/stl/_num_get.c:118
if ((-__result == (numeric_limits<_Integer>::min)()) && !__is_negative)
__ovflow = true;
if (__is_group && __group_sizes_end != __group_sizes) {
*__group_sizes_end++ = __current_group_size;
}
2. For short issue.
It can be fixed by such a simple way.
We found a short version *get() *lies at stlport/stlport/stl/_num_get.h#70.
But it was disabled by macro _STLP_FIX_LIBRARY_ISSUES.
Can you give us any hints why they have been omitted as we found nothing
from the commit/upgrade logs?
69#*if* *defined* (_STLP_FIX_LIBRARY_ISSUES)
70 _InputIter get(_InputIter __ii, _InputIter __end, ios_base& __str,
71 ios_base::iostate& __err, *short*& __val) *const*
72 { *return* do_get(__ii, __end, __str, __err, __val); }
73
74 _InputIter get(_InputIter __ii, _InputIter __end, ios_base& __str,
75 ios_base::iostate
<http://sourcebrowser.tl.intel.com:8080/source/s?defs=iostate&project=ABSP_R4_JB_main>&
__err, *int*& __val) *const*
76 { *return* do_get(__ii, __end, __str, __err, __val); }
77#*endif*
Thanks.
On Mon, Jun 3, 2013 at 5:19 PM, Chenyang <du...@gm...> wrote:
> This issue were seen on Android.
> Many libs and apps will depend on STLPort.
> We want to know whether it will be fixed in future release.
> Currently, we have a patch to fix the issue with *long long* type.
> But for *short* type, huge revision may be needed.
>
>
>
> On Mon, Jun 3, 2013 at 2:02 PM, Petr Ovtchenkov <pt...@vo...> wrote:
>
>> On Fri, 31 May 2013 09:54:06 +0800
>> Chenyang <du...@gm...> wrote:
>>
>> > ...
>> > An issue with the stlport library has been found. The string conversion
>> to
>> > long long or short does not have the expected behavior.
>> >
>>
>> The operations related to numbers representation isn't perfect in STLport.
>>
>> The facility of 'small simple fixes' was exhausted in this area.
>>
>> The key point is incorporation of a library with implementation of
>> abitrary (well, may be not abitrary..., but 'enough') precision
>> rational arithmetic.
>>
>> Possible ways are:
>>
>> - implement such library within STLport project
>>
>> - use well-designed library (GMP/MPFR/etc.)
>>
>> - us not well-known library (what?)
>>
>> In any case, numeric representation code require deep revision.
>>
>> --
>>
>> - ptr
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite
>> It's a free troubleshooting tool designed for production
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>> http://p.sf.net/sfu/appdyn_d2d_ap2
>> _______________________________________________
>> stlport-bugs mailing list
>> stl...@li...
>> https://lists.sourceforge.net/lists/listinfo/stlport-bugs
>>
>
>
>
> --
> Chenyang
>
--
Chenyang
|
|
From: Chenyang <du...@gm...> - 2013-06-03 09:19:17
|
This issue were seen on Android. Many libs and apps will depend on STLPort. We want to know whether it will be fixed in future release. Currently, we have a patch to fix the issue with *long long* type. But for *short* type, huge revision may be needed. On Mon, Jun 3, 2013 at 2:02 PM, Petr Ovtchenkov <pt...@vo...> wrote: > On Fri, 31 May 2013 09:54:06 +0800 > Chenyang <du...@gm...> wrote: > > > ... > > An issue with the stlport library has been found. The string conversion > to > > long long or short does not have the expected behavior. > > > > The operations related to numbers representation isn't perfect in STLport. > > The facility of 'small simple fixes' was exhausted in this area. > > The key point is incorporation of a library with implementation of > abitrary (well, may be not abitrary..., but 'enough') precision > rational arithmetic. > > Possible ways are: > > - implement such library within STLport project > > - use well-designed library (GMP/MPFR/etc.) > > - us not well-known library (what?) > > In any case, numeric representation code require deep revision. > > -- > > - ptr > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > stlport-bugs mailing list > stl...@li... > https://lists.sourceforge.net/lists/listinfo/stlport-bugs > -- Chenyang |
|
From: Petr O. <pt...@vo...> - 2013-06-03 06:31:45
|
On Fri, 31 May 2013 09:54:06 +0800 Chenyang <du...@gm...> wrote: > ... > An issue with the stlport library has been found. The string conversion to > long long or short does not have the expected behavior. > The operations related to numbers representation isn't perfect in STLport. The facility of 'small simple fixes' was exhausted in this area. The key point is incorporation of a library with implementation of abitrary (well, may be not abitrary..., but 'enough') precision rational arithmetic. Possible ways are: - implement such library within STLport project - use well-designed library (GMP/MPFR/etc.) - us not well-known library (what?) In any case, numeric representation code require deep revision. -- - ptr |
|
From: Chenyang <du...@gm...> - 2013-05-31 01:54:13
|
Hi Guys,
Sorry for
re-
sending this message as it has been sent to the wrong maillist.
An issue with the stlport library has been found. The string conversion to
long long or short does not have the expected behavior.
Below are two simple example programs:
Simple 1, issue related to short:
---------------------------------------------------------------------------------
The patch works fine for long long long/int but not for short.
#include <iostream>
#include <limits>
#include <sstream>
#include <string>
using namespace std;
int main(int argc, char **argv)
{
cout << "This is the upper bound of short " <<
std::numeric_limits<short>::max() << endl;
cout << "Now if I try to convert le above value +1 which is 32768" << endl;
std::stringstream ss("32768");
short result;
ss >> result;
cout << "It should fail..." << endl;
if (ss.eof() && !ss.fail() && !ss.bad())
cout << " but it does not..." << result << endl;
if (result == std::numeric_limits<short>::min())
cout << " And result is now min." << endl;
return 0;
}
gives :
This is the upper bound of short 32767
Now if I try to convert le above value +1 which is 32768
It should fail...
but it does not...-32768
And result is now min.
Simple 2, issue related to long long:
---------------------------------------------------------------------------------
#include <iostream>
#include <limits>
#include <sstream>
#include <string>
using namespace std;
int main(int argc, char **argv)
{
cout << "This is the upper bound of long long " <<
std::numeric_limits<long long>::max() << endl;
cout << "Now if I try to convert the above value +1 which is
9223372036854775808" << endl;
std::stringstream ss("9223372036854775808");
long long result;
ss >> result;
cout << "It should fail..." << endl;
if (ss.eof() && !ss.fail() && !ss.bad())
cout << " but it does not..." << result << endl;
if (result == std::numeric_limits<long long>::min())
cout << " And result is now min." << endl;
return 0;
}
If you compile this and run it on the board, you get the following output:
This is the upper bound of long long 9223372036854775807
Now if I try to convert the above value +1 which is 9223372036854775808
It should fail...
but it does not...-9223372036854775808
And result is now min.
This behaviour is wrong as the conversion ss>> result should fail.
You may test this on your linux machine, the result is correct.
You may also notice that I have some similar issue with long (instead
of long long)
Note that if you try to convert the max value +2, the conversion fails
(looks like a off by one somewhere).
--
Chenyang
|
|
From: SourceForge.net <no...@so...> - 2008-10-07 09:49:13
|
Bugs item #2151096, was opened at 2008-10-07 18:48 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=2151096&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: 5.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Maxim Yanchenko (enerjazzer) Assigned to: Nobody/Anonymous (nobody) Summary: operator>>(void*&) doesn't work Initial Comment: Hi, it looks like operator>>(void*&) doesn't work (i.e. the default num_get::do_get(...,void*&) doesn't work). See this simple test: #include <iostream> #include <sstream> #include <stdio.h> int main() { int q=5; void *x1=&q, *x2=0, *x3=0; std::cerr << "x1: " << x1 << std::endl; std::cerr << "x2: " << x2 << std::endl; std::stringstream ss; ss << x1; ss >> x2; std::cerr << "x2: " << x2 << std::endl; char sss[256] = ""; fprintf(stderr, "x1 = %p\n", x1); fprintf(stderr, "x3 = %p\n", x3); sprintf(sss, "%p", x1); sscanf(sss, "%p", &x3); fprintf(stderr, "x3 = %p\n", x3); } compiling with gcc 3.4.6. output with gcc standard library: x1: 0x7fbffff11c x2: 0 x2: 0x7fbffff11c x1 = 0x7fbffff11c x3 = (nil) x3 = 0x7fbffff11c output with STLPort 5.1.5: x1: 0x0000007fbffff11c x2: 000000000000000000 x2: 000000000000000000 x1 = 0x7fbffff11c x3 = (nil) x3 = 0x7fbffff11c same locale settings. As you can see, STLPort fails to load a pointer. According to the Standard, it should work both ways as printf/scanf's %p, which is two-way working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=766244&aid=2151096&group_id=146814 |
|
From: SourceForge.net <no...@so...> - 2008-10-04 10:18:05
|
Bugs item #2146163, was opened at 2008-10-04 12:18 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=2146163&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: Operational Environment/Compiler specific code Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Big Muscle (bigmuscle) Assigned to: Nobody/Anonymous (nobody) Summary: SVN3693 doesn't work correctly Initial Comment: When I try to build STLPort SVN3693 with macros _STLP_USE_PTR_SPECIALIZATIONS or _STLP_DONT_USE_SHORT_STRING_OPTIM, I receive error (something wrong in type traits) and compilation stops. If I undefine these macros, it builds ok. Although STLPort builds ok then, I can't build my own application with this SVN3693. It displays following error: stlport\stlport\stl\_vector.h(403) : error C2664: 'stlp_std::allocator<_Tp>::allocate' : cannot convert parameter 2 from 'stlp_std::vector<_Tp>::size_type' to 'const void *' I have MSVC 2008 with SP1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=766244&aid=2146163&group_id=146814 |
|
From: SourceForge.net <no...@so...> - 2008-08-28 04:31:16
|
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: Operational Environment/Compiler specific code Group: None >Status: Closed >Resolution: Fixed Priority: 1 Private: No Submitted By: Alex Tartakovsky (tartak) Assigned to: Nobody/Anonymous (nobody) Summary: Unit FstreamTest::tellp fails on Windows 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-28 08:31 Message: Logged In: YES user_id=615813 Originator: NO Applied for 5.2 branch; applied for trunk (will be committed later, ASAP). ---------------------------------------------------------------------- Comment By: Alex Tartakovsky (tartak) Date: 2008-08-28 05: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-28 00: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 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 |
|
From: SourceForge.net <no...@so...> - 2008-08-28 01:15:10
|
Bugs item #2070991, was opened at 2008-08-24 02:56 Message generated for change (Settings changed) 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 on Windows 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 |
|
From: SourceForge.net <no...@so...> - 2008-08-28 01:12:46
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-27 18:54:52
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-27 16:30:29
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-26 05:40:23
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 20:31:42
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 19:08:29
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 17:17:29
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 13:58:42
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 12:41:03
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 12:01:18
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 11:03:14
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 07:34:45
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 07:03:33
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-25 05:52:18
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-24 15:08:48
|
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 |
|
From: SourceForge.net <no...@so...> - 2008-08-24 06:56:15
|
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 |
1 message has been excluded from this view by a project administrator.