Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: svn commit: r646002 - /stdcxx/trunk/util/output.cpp
Date: Tue, 8 Apr 2008 15:43:11 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA7FE@exchmail01.Blue.Roguewave.Com>
Thread-Topic: svn commit: r646002 - /stdcxx/trunk/util/output.cpp
Thread-Index: AciZudndGGDgtA5zThSNyDCduijLNAABRxHQ
References: <20080408171236.E3AF11A983A@eris.apache.org>
 <CFFDD219128FD94FB4F92B99F52D0A49010A36E0@exchmail01.Blue.Roguewave.Com>
 <47FBD997.5040601@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

>Andrew Black wrote:
>
>Not a whole lot of work it seems.
>
>I've been looking into this problem this afternoon, and I believe I've
>determined a solution.
>
>The initial issue (which Farid spotted) was that windows has an fread
>behavior which differers in subtle ways from that on unix systems.  In
>particular, it performs CRLF to CR translation when it reads a file in
>text mode, and as a result the number of characters read into=20
>the buffer
>is less than the number of bytes which the operating system=20
>was asked to
>read. This differs from the POSIX spec which reads in part 'Upon
>successful completion, fread() shall return the number of elements
>successfully read /which is less than nitems only if a read error or
>end-of-file is encountered/.' (My emphasis on the second half=20
>of the quote).
>
>The solution (as implemented by Farid and Travis) was to read the input
>files in binary mode, rather than text mode. The problem with this
>solution is that it causes differences in line endings to show up as
>differences where this is none.  These differences in line endings are
>introduced by the creation of the nightly testing archive (on a unix
>system with unix line endings), but the run being performed on=20
>a windows system (with the output using windows line endings).

Arg! I knew my code worked when I tested it. Now it all makes sense.

>
>My solution (attached) removes the checks on the return from fread, and
>saves that value in the readback structure as the pointer into the read
>buffer.
>

I think the following block [from msdn fseek() documentation] throws
a wrench into the works.

    For streams opened in text mode, fseek and _fseeki64 have limited
    use, because carriage return-linefeed translations can cause fseek
    and _fseeki64to produce unexpected results. The only fseek and
    _fseeki64 operations guaranteed to work on streams opened in text
    mode are:=20

      * Seeking with an offset of 0 relative to any of the origin
        values.

      * Seeking from the beginning of the file with an offset value
        returned from a call to ftell when using fseek or _ftelli64
        when using _fseeki64.

The latest patch uses fseek() in a manner that is inconsistent with
these requirements. I'm not totally certain of what the behavior will
be, but I'd guess that it is not good.

If the problem of the example diffs is being caused by opening the diff
file in binary mode, then I suggest we leave it as text for that case.
The pseudo-patch I sent in my previous message should work to address
the problem. It isn't ideal, but it does work and is quite simple.

Travis

>--Andrew Black