readline() strangeness on 4.8.10D4

[Roger Cornelius]

On 12/16/2008 23:29, Kenneth Brody wrote:
> Quoting Roger Cornelius (Tue, 16 Dec 2008 17:30:43 -0500):
>
>> Filepro 4.8.10D4 on SCO OSR507
>>
>> I'm seeing strange behaviour from readline(), which I haven't had a need
>> to use before now.  Or maybe it's len() or call processing or the
>> debugger that's the problem.
>>
>> - I'm using a called table via "call noauto"
>> - In auto processing I have field kz(12,*)
>> - In called table I have field kz(64,*)
> [...]
> ... readline() works, but len(kz) and the debugger show 12 characters ...
> [...]
>
> Sounds like an issue with len() and the debugger, as readline() is
> returning the proper 64 characters.
>
> [...]
>> And also:
>>
>> - readline() doesn't like it when it's arguments are variables with long
>>   names.  At least I get a syntax error when I try to save the table.
>>   writeline() seems to work fine with long name variables.
>>
>> Since we're on an old fp version, can I assume these issues have already
>> been reported and fixed?  If so, in what version?
>
> As noted in the 4.8.12 readme:
>
> All
>     READ()/READLINE() now accept long-named variables as the second
>     parameter.
>
>> Am I going to have problems reusing vars which exist in auto processing
>> even though I'm using "call noauto"?
>
> Define "problems".
>
> By using CALL NOAUTO, you are telling filePro that the CALLed table is
> to not share the dummy fields which may be defined in auto processing.
> In this case, the CALLed table's "kz" field is local to that table, and
> not the one already defined in auto, which would have happened with a
> "normal" CALL.  The same holds true for all other dummy fields.

By "problems", I mean could vars used in both auto and called processing
stomp on each other even though I'm using "call noauto"?  This, given
the fact that the debug mode "F" command, from the called table, shows
the length and value of the field as defined in auto processing and not
called processing.  If there's a bug that allows debug mode to see the
auto processing version of the var, what's to say the bug doesn't also
allow other areas of processing to see the auto version of the var?

To put it another way, if we know the "auto processing vars not visible
in call noauto processing" concept is broken in debug mode, how can we
know if it's not also broken in other areas?

Does that make sense?
-- 
Roger Cornelius            rac at custom-mobility.com