Re: [perl #37711] undefined hashref error reported on wrong line

[Jim Cromie <jim.cromie@gmail.com>]

Dave Mitchell wrote:

>On Fri, Nov 18, 2005 at 05:08:05PM -0800, David Hillman wrote:
>  
>
>>When a hashref being used as a 'while condition' runs out, the  
>>resulting undefined error is reported from the last
>>line of the loop, instead of the first.
>>    
>>
>
>Thanks for the report. There are a number of similar bugs present in the
>perl interpreter.
>
>p5pers:
>
>A generic fix to this would be attach the line number to *every* op rather
>than just to control ops (we'd still get the file name from the last cop).
>The cost of this is an extra 4 bytes per op. Is this worth the memory
>cost?
>
>  
>
hmm. this may border on the grotesque, but hopefully I will have the
good sense to consider killing this msg b4 actually sending it. (or not..)

assumptions & observations;

- rarely need extra info. make it a pragma, ?
    and use only when/where needed.

- only tokenizer could know line-numbers with sufficient detail to
    collect them inside an expression.

- only machine-generated expressions will exceed 255 lines (this is 
debug support after all)
    a tiny-int / char would be sufficient to remember lines

- assume line-num per opcode is useful.
    ideally users want to know line numbers of terms and operators,
    how to compute line-nums for terms  based on those of opcodes

- denser encodings are possible:
struct extra_cop_line_info {
    int    MaxOPs_per_COP;
    bool  incvec[MaxOPs_per_COP];  // loosely 1 flag per opcode.
    unsigned char nextline[MaxOPs_per_COP];
};
so. if an op is on same line as the previous (*), then its incvec bit is 
zero.
else the bit ==1 says that next byte in nexline[] field is an offset 
from the COP line-num.
And MaxOPs_per_COP can be dynamically set to the number of opcodes
attached to a COP, once its known for each statement.

- hang this optional cop-related info off the cop; then pointer overhead 
is reduced.

- create new cop sub-type that has the room for the extra info.
    this is vaguely similar to nextstate vs dbstate,
    and avoids unused storage (if it can be properly pragma controlled)


ugly is as ugly does ;-)
jimc

---

Follow-Ups from:

"H.Merijn Brand" <h.m.brand@xs4all.nl>
Nicholas Clark <nick@ccl4.org>

References to:

David Hillman (via RT) <perlbug-followup@perl.org>
Dave Mitchell <davem@iabyn.com>

---

[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index][Thread Index][Top&Search][Original]

---