JK>    Please let me know how I should proceed.  If it comes down to
JK>    it, I'm going to have to rewrite 5,000 lines of code at the cost
JK>    of another $25,000 of my time.  And all for a $19.95 upgrade.
JK>    
DN>What do you think we should do?  Internally, we have switched all
DN>projects (large and small) over to PowerBASIC 3.2 without any problems.
DN>Additionally, PowerBASIC 3.2 has been shipped to tens of thousands of
DN>customers at this point.  And I have received no such reports from any
DN>of those customers.
        And I wish I could be one of the tens of thousands who didn't
        have a problem to report.  ;)  I like to think that I write code
        so advanced that it turns up subtle oversights in a compiler.
        
DN>Not to say that you haven't found a legitimate problem or bug.  But
DN>based on your message, how should we go about finding it?  Nothing we
DN>have produces it.  How do you find a bug which you can't reproduce?
        I can reproduce the problem using my source code by changing one
        line of code from:
        REDIM OutClauseArray(x) AS ClauseTableType
        to:
        REDIM OutClauseArray(x)
        The above code does not produce a problem when compiled under
        3.1, but does produce a nasty problem when compiled under 3.2.
DN>You have to look at this from our point of view.  We receive hundreds of
DN>bug reports a *week* and only 1 out of about 5,000 turns out to be a
DN>legitimate bug.  99.9% of the time it's user error.
        I understand your point of view.  If what I have uncovered is a
        genuine run-time exception, then it becomes meaningful to
        isolate it and reproduce it under lab conditions.  My problem is
        that the code in which it occurs is thousands of lines of
        state-of-the-art proprietary work.  I will try to either emulate
        the error in the lab using a shorter control, or I will whittle
        away as much of my proprietary code as I can, while still
        maintaining the error for the PB tech staff to scrutinize.
DN>I agree that if something compiles fine under 3.1, it should compile
DN>fine under 3.2.  However, you mention in your message that you have
DN>ported over a lot of it to features of PowerBASIC 3.2.  Therefore, I
DN>would have to suspect that the problem lies in the code which has been
DN>modified.  Likely to be user error on your part during the 'porting'
DN>process.
        Well, I'd like to say it was that, too, but the exact same code
        that compiled and ran fine under 3.1 produced heap errors and
        random problems under 3.2, without a single change.  Only after
        I used single-stepping to isolate the problem to the REDIM
        statement was I able to fix the problem.  Since, technically,
        the problem has been rectified, there is no problem.  However,
        the REDIM documentation does not demand an AS TYPE clause, nor
        does the PB compiler, so who knows where a similar error might
        pop up in one of those tens of thousands of programmers' code?
        As I say, I'd be more than pleased as punch to find out that I'm
        at fault.
DN>If you have code which you can send us which actually
DN>demonstrates the problem, we'd be happy to take a look at it and fix it,
DN>if indeed it is a problem with the compiler.  But without something to
DN>demonstrate the problem on our end, there's little help that I can
DN>offer.  I hope you understand.
        Of course I understand.  I just cannot demonstrate the problem
        with the proprietary code I have.  I suppose a non-competition
        and non-disclosure agreement from PB would allow me to submit
        the proprietary code for scrutiny, and I could heavily comment
        the section of code that produces the result.  Also, I could PBU
        all but the critical section of code ... or as stated above, I
        can whittle away as much of my proprietary code as possible, so
        that the error is still in the whittled down version, while
        protecting AhuraMazda(tm) Software's trade secrets.
        Any of the above proposals would at least uncover the source of
        the problem, I should think.  I wish I could just post the code
        in this echo, but you must understand that all 8,000 lines would
        be required to reproduce the problem, and I cannot reveal the
        code without some legal protection.  That's the nature of
        cutting edge software development.
        In the meantime, I'll try to reproduce it with a control in the
        lab rather than have to follow through on the whittling or the
        NDA.
        I appreciate your taking your time to figure out a solution.
        It might assist you in your decision on how to pursue this
        problem if I list the facts:
                1.  Identical code, when compiled under 3.1 and 3.2 only
                    produces an IDENTIFIABLE problem in the 3.2 version.
                2.  The problem can be traced to an exact section of my
                    code, and always produces the same error condition.
                3.  The problem is rectified by adding an AS TYPE
                    clause in the v3.2 code that is not strictly
                    required in the v3.1 code, and therefore, it can be
                    said that it is a problem introduced specifically
                    since the 3.2 compiler.
        Here are some other points:
                1.  I cannot submit the code for PB scrutiny without an
                    NDA and non-competition agreement from PB, since it
                    is s-o-t-a and proprietary to AMS.
                2.  I might be able to submit a PBL that includes 90% of
                    the code and a whittled down version of the error
                    producing code.
        Dave, you understand that I have already found a fix for the
        problem ... just use AS TYPE with all REDIM's.... The question
        is no longer how much time I am going to lose by tracking the
        thing down....  The question is -- is it worth PB's time to
        scrutinize the problem to determine if it is programmer error or
        a legitimate v3.2 problem?
        This is stated without prejudice, of course.  I am more than
        happy with 3.2 now that I've found the fix.  At the very least,
        if it is a legit problem, the documentation for REDIM could
        include a mention that the AS TYPE clause may prevent "potential
        problems" in non-trivial programs.
Jamshid
 * OLX 2.1 TD * Oxymoron: Microsoft Customer Service
--- Maximus/2 2.01wb
---------------