kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/03/2013 03:26 PM, Maciej Sumiński wrote:
> Hi Dick,
>
> Sorry for all the troubles associated with the GAL, but surely soon it 
> will get stable. The reason is, as you suspected - an unexpected layer 
> in the file. I propose the patch from the attachment, I think it is 
> better to treat unknown layers as COMMENTS. Still I am wondering - how 
> does KiCad handle items with negative layer numbers by default?

I would say that a negative layer number is illegal, and any such call to "accessor"
SetLayer() with a -1 is a bug, regardless of where it is happening.  It is times like this
that accessors come in handy, because they can serve as a bug trap by outfitting them with
an assert() or print statement or breakpoint.  I would even go so far as to say that
accessors spend their whole lives waiting for this one moment on stage.

Thanks for tracking this down.  The actual bug was in EAGLE_PLUGIN, but for me to
determine that was not a walk in the park since the manifestation was in the new code and
it was late at night when I stumbled onto it.


I chose a different solution for the fix, although the net effect for this type of circle
object is the same.  I just did not go with your patch because it kept all objects
originating on unsupported layers, and thus made COMMENT_N into a junk yard.  (Some things
simply need to be thrown away.)


The -1 has been changed to UNDEFINED_LAYER, but more importantly, all callers to
EAGLE_PLUGIN::kicad_layer() now test the return value and make their own decisions about
the appropriateness of the translated layer.  In no case is UNDEFINED_LAYER stuffed into
BOARD_ITEM::SetLayer().


Thanks much again for your time,

Dick