Sounds good. For now, I’ll keep the hack in to avoid the error. Once the alternative solution is in place, I’ll back it out and give it a whirl. I’m enabled for now.
On Sun, Nov 11, 2018 at 16:19 Tim Edwards <t...@opencircuitdesign.com> wrote: > 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
