[Oorexx-bugs] [ oorexx-Bugs-2016732 ] ~lines() failure in 4.0

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

Bugs item #2016732, was opened at 2008-07-12 13:40
Message generated for change (Comment added) made by bigrixx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2016732&group_id=119701

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: Interpreter
Group: v4.0
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Mark Miesfeld (miesfeld)
>Assigned to: Rick McGuire (bigrixx)
Summary: ~lines() failure in 4.0

Initial Comment:
Rick, I know you are probably busy working on the Linux build and I'm busy right now too.  So, I'm just going to open a bug for this so it doesn't slip through the cracks.

There is a kinda corner case with lines that fails on 4.0 and works on 3.2.0.

This test case catches it:

[failure] [20080712 10:10:28.941000]
  Test:   TEST_ZDESTINATIONA
  Class:  Monitor.testGroup
  File:   E:\work.ooRexx\ooRexxUnit\3.x\ooRexx\base\class\Monitor.testGroup
  Line:   96
  Failed: assertEquals
    Expected: [[1], identityHash="267903561"]
    Actual:   [[0], identityHash="267917288"]

But this simple program also demonstrates it:

/* Demonstrate ~lines() failure in 4.0 */

  fsObj = .stream~new("testFile.txt")

  fsObj~open('Write Replace Nobuffer')
  fsObj~lineout("Line 1")

  say "How many lines in file?" fsObj~lines
  fsObj~close

The above fails on 4.0 and works on 3.2.0:


E:\work.ooRexx\3.x\interpreter\Win32Dbg>rexx -v
Open Object Rexx Interpreter Version 4.0.0 - Internal Test Version
Build date: Jul 12 2008
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2008.
...
E:\work.ooRexx\3.x\interpreter\Win32Dbg>
E:\work.ooRexx\3.x\interpreter\Win32Dbg>.\rexx ..\linesTest.rex
How many lines in file? 0


E:\work.ooRexx\3.x\interpreter\Win32Dbg>killer rxapi
RXAPI.EXE (Process ID: 3092) killed successfully

E:\work.ooRexx\3.x\interpreter\Win32Dbg>d:

D:\>cd Interpreters\Rexx\ooRexx.3.2.0.release

D:\Interpreters\Rexx\ooRexx.3.2.0.release>.\rexx -v
Open Object Rexx Interpreter Version 3.2.0
Build date: Oct 30 2007
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2007.
...
D:\Interpreters\Rexx\ooRexx.3.2.0.release>.\rexx linesTest.rex
How many lines in file? 1

The basic failure is in StreamNative.cpp here:

    // non-binary persistent stream...these are a pain
    else
    {
        int64_t currentSize = size();

        // if our read position is in no-man's land, this is zero
        if (charReadPosition > currentSize)
        {
            return 0;
        }

Size comes back as 0.  I fooled with this about a week ago and didn't see a good fix.  However, I was just looking at it again and maybe see what to do.

So, I might get to it before you, if not this bug will prevent forgetting about it.

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

>Comment By: Rick McGuire (bigrixx)
Date: 2008-07-12 14:45

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

Ok, I stand corrected.  If WRITE mode is specified, the stream will still
be opened READ WRITE if possible.  This uncovered about 4-5 separate bugs
in the stream library. 

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

Comment By: Rick McGuire (bigrixx)
Date: 2008-07-12 13:54

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

Mark, 

I think the 4.0 gets this one correct and the 3.2.0 code is the one in
error.  lines() does not return the count of lines in the file, but rather
returns the count of lines available for reading (or 1, if there are lines
available, but the count can't be determined).  For a file opened for
WRITE, this should always return 0.  However, if I specify BOTH, then it
still returns 0, so there is a bug in the code too. 

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2016732&group_id=119701