Hello Dan,
> Lines 1565-1569. What's happing is that a pointer to a Tcl_Obj is being
> passed to the function. https://www.tcl.tk/man/tcl/TclLib/Object.htm
> The longValue (datatype: long) is retrieved from this structure. Its
> value correctly corresponds to the hex string. It is the cast to the
> int and then back to a long on line 1566 is the culprit. When the
> handle's value is greater than what can be stored in an int, then data
> loss will occur. The if on line 1566 no longer evaluates to true and
> the function doesn't return and falls through to returning the
> TCL_ERROR.
>
> I'm not sure where the "too large" message is supposed to appear, but
> I didn't notice it in either the console nor in the terminal that
> executed xcircuit.
>
> As an experiment, I commented out lines 1566 and 1569 and recompiled.
> Now things worked out as expected. That is, the form got expanded with
> the pin list, and once Okay'ed the symbol is created. ...and no error.
>
> I didn't dig further to determine why handles need to be restricted
> to the size of an int, but it doesn't seem to matter (yet).
>
> Anyone have some insight on this?
This code is dependent on the definition of "int", which as you may
know, is a wishy-washy concept in C which is often (but not necessarily)
defined as 4 bytes on a 32-bit system and 8 bytes on a 64-bit system;
and also the definition of "long", which is an equally wishy-washy
concept and may be twice the size of "int". . . or not. I no longer
remember why I wrote that snippet of code, but I think that I was just
guarding against the possibility that the Tcl object "longValue" would
be the same length as a pointer. If it is shorter, then the error
would alert me that I need to do something completely different here,
which is either to find some Tcl_Obj representation that is always the
length of a pointer, or (probably a better approach anyway) to avoid
the use of a memory location as the "handle" to an object in xcircuit,
and instead generating a random (and likely much shorter) value for
the handle of each object as needed, and create a hash table out of
that.
Removing lines 1566 to 1569 "almost always" solves the problem, but
because you are chopping half of the object's unique address off (this
is assuming it is probably a 32-bit vs. 64-bit issue), the remainder of
the number is "probably" unique to the object, but that is not guaranteed.
So while it is highly unlikely that you will ever encounter an error
caused by removing those lines of code, I would rather solve the problem
in the "correct" way by assigning a unique handle ID to each element and
then doing look-ups from a hash table.
I'll put that on my to-do list, but feel free to send me a reminder if
you find I haven't gotten around to it after a week or so.
Regards,
Tim
+--------------------------------+-------------------------------------+
| R. Timothy Edwards (Tim) | email: t...@opencircuitdesign.com |
| Open Circuit Design | web: http://opencircuitdesign.com |
| 19601 Jerusalem Road | phone: (240) 489-3255 |
| Poolesville, MD 20837 | cell: (408) 828-8212 |
+--------------------------------+-------------------------------------+
_______________________________________________
Xcircuit-dev mailing list
Xcircuit-dev@opencircuitdesign.com
http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
