Ints are usually just 32 bits – at least on popular 64-bit architectures such as amd64, arm, and IIRC ppc. So sizeof(int)==sizeof(int32_t) but also there sizeof(void*)==sizeof(int64_t), and pointers-in-integer should be carried in [u]intptr_t and not in a sized integer either. If one needs an integer of particular size, use [u]int_##t from <stdint.h> instead of plain int. Usually one wouldn’t want to replicate int size detection code – almost all reasons for it reduce to not using standard sized integer types. On very old platforms that don’t come with stdint.h, one can have their own replacement of same name with whatever magic is desired, of course. That’s what I make of it, at least.
Cheers, Kuba > 11 nov. 2018 kl. 19:19 skrev Tim Edwards <t...@opencircuitdesign.com>: > > 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 _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev@opencircuitdesign.com http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev
