Re: [Stlport-devel] SF.net SVN: stlport:[3611] trunk/STLport

[Ulrich E. <eck...@sa...>]

On Wednesday 23 July 2008, Petr Ovtchenkov wrote:
> ISO/IEC 2003 (and draft too):
> ...
> It then opens a file, if possible, whose name is the NTBS s (‘‘as if’’ by
> calling std::fopen(s,modstr)).
> ...
>
>    ios_base Flags combination
>      out         app             stdio equivalent
> ...
>      +            +                 "a"
> ...
>
>
> conflict with:
>
> +    ofstream o( "test_file2.txt" );
> -    ofstream o( "test_file.txt", ios_base::app | ios_base::out );

Wait: it could be that you are misinterpreting what is going on here. I guess 
you are referring to revision 3611. That revision changes (unfortunately) 
several things at once:

1. Remove 'app' from valid openmodes in the implementation because it isn't 
standard. It leaves 'in|app' and 'in|out|app' in though, which are both 
nonstandard, too.

2. It removes the two checks that the streamposition after opening a file 
containing just "123456789" using either ofstream(.., app) or fopen(..,"a") 
is at position 9. This check (like the reporter of #2001222) makes the 
assumption that after opening for appending the file position must already be 
at the end of the file, but there is no reason for that assumption. If you 
want that, rather use 'ate'.

{Guys: Actually writing down what you intend to test would have saved us from 
this confusion, preferably with a reference to chapter and verse of what 
behaviour is checked. Remember: you don't write comments for yourself but for 
the next guy hacking on the code. Don't assume he knows the same as you do!}

3. It adds a check that the position after fopen(..,"a") is the same as with 
ofstream(..,app), i.e. that C++ IOStreams and C stdio behave the same. I 
think the reason for that is that ofstream's behaviour is defined in terms of 
fopen() behaviour, so this check just makes sure they both behave the same 
indeed.

4. It adds a check that ofstream(.., app|ate) on a file containing "123456789" 
will report 9 as current write position. This corresponds to the reported bug 
and checks that the correct fix for the submitter's code also works.

> I mean that I can write
>
> ofstream o( "test_file.txt", ios_base::app | ios_base::out );
>
> This sentence acceptable both in ISO/IEC 2003 and in draft,

Right, this is perfectly acceptable C++, but...

> and just removing this line not acceptable, especially it's the origin
> of question. _Changing_ the _correct_ tests along with 'fix' looks like
> cheating at play.

...just the fact that one line of valid C++ was removed doesn't make this 
change not acceptable! You have to look at a slightly bigger context (see 
above).

> > It seems the standard indeed says that the write position is set to the
> > end of the file before every write operation. From that doesn't follow
> > that its write position must already be at the end after opening it. I
> > find this wording bad, either it should require that it is positioned or
> > explicitly allow it to now be positioned at the end. However, it doesn't
> > change that there are _no requirements_ on the write position after
> > opening the file!
>
> Both in ISO/IEC 2003 and draft present explicit reference:
>
> <cite>
>  ... ‘‘as if’’ by calling std::fopen(s,modstr) ...
> </cite>
>
> so the reference in unit tests to behavior of fopen as 'what expected here'
> is correct and follow to ISO/IEC 2003 too.

I agree that comparing the behaviour of fstreams to that of C stdio is correct 
in all the cases where the standard defines the fstream behaviour in terms of 
C stdio, like above reference to fopen().

> In comments about our issue I don't saw explicit words like:
>
> 'on platform X fopen( "foo.txt", "a" ) not set the g-pointer to EOF
> position'
>
> as expected (and don't know, whether it really happens or not).

If we have a platform where fopen() didn't behave as required, I think we 
should work around that in fstreams implementation. Of course, then we can't 
use the C stdio behaviour any more in order to determine whether our 
implementation is correct. Excluding these checks on that platform with a 
suitable comment explaining the situation should do the job.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.

**************************************************************************************