Posted to tcl by jima at Wed May 14 07:48:44 GMT 2014view raw
- [16:28] dgp general advice: do not use Tcl_ConvertToType()
- ...
- [16:33] * jima thanks dgp for the advice... the crash was due me not initializing an extension properly
- [16:34] dgp yes, so now you're in the situation I feared you would be in.
- ...
- [16:34] dgp Fixed the segfault, but still using T_CTT().
- [16:35] jima yes, still use T_CTT was called in code depending on the extension
- [16:35] jima the extension is VecTcl ... and it relies in type conversion to deal with lists <=> arrays
- [16:35] jima (I think)
- [16:35] hypnotoad In general, you recommend making a copy with "Tcl_XXXFromObj()"?
- [16:36] dgp It's possible you're working in one of the few dark corners where a T_CTT() call is the least awful thing you can do.
- [16:36] jima not me, Christian
- [16:36] hypnotoad
- [16:36] jima unluckily he does not come to the chat (yet...)
- [16:36] emiliano wanders in.
- ...
- [16:36] jima I am just trying to use his extension
- [16:37] jima in conjunction with another one coming from Arjen...
- [16:37] jima (having fun these days)
- [16:37] hypnotoad I just ask because I am working on an extension that create native Tcl_Objs for geometry constructs and vectors
- [16:37] dgp So what intrep intrusions is VecTcl guilty of then?
- [16:38] jima https://github.com/auriocus/VecTcl
- [16:38] jima is the home of the extension
- [16:38] jima I am following https://github.com/auriocus/VecTcl/blob/master/APIdemo/generic/lsvd.c
- [16:38] jima this particular piece
- [16:38] jima /* Convert the 1st argument to VecTcl object */
- NumArrayInfo *info = NumArrayGetInfoFromObj(interp, matrix);
- if (!info) { return TCL_ERROR; }
- [16:39] jima calls it
- [16:39] <awb> exits, stage left!
- [16:39] dgp not at that link
- [16:40] jima /* Extract the NumArrayInfo* from a Tcl_Obj
- * If naObj can't be converted to NumArray,
- * NULL is returned */
- NumArrayInfo *NumArrayGetInfoFromObj(Tcl_Interp *interp, Tcl_Obj* naObj) {
- if (Tcl_ConvertToType(interp, naObj, VecTclNumArrayObjType) != TCL_OK) {
- return NULL;
- }
- return naObj -> internalRep.twoPtrValue.ptr2;
- }
- [16:41] emiliano exits, stage left!
- [16:41] jima At https://github.com/auriocus/VecTcl/blob/master/generic/vectclapi.c
- [16:41] dgp ok, that's fairly harmless.
- [16:41] jima yes
- [16:41] jima the mistake was totally on my side
- [16:42] jima I lacked a VecTcl_InitStubs call
- [16:42] dgp better would be to call the "SetFromAny proc direct.
- [16:42] dgp T_CTT() just obfuscates things.
- [16:43] * jima noted
- [16:43] * hypnotoad also noted
- [16:43] dgp I think experience has shown....
- [16:44] dgp ....that it's best for a Tcl_ObjType author *not* to call Tcl_RegisterObjType()....
- [16:44] hypnotoad Oh?
- [16:44] dgp ...but instead to provide a My_GetFooFromObj() routine.
- [16:44] dgp objtype registration is an error wrapped in a mistake.
- [16:45] hypnotoad Well that makes my job easier...
- [16:45] tpoindex is feeling chatty!
- [16:46] dgp name conflicts opportunities, with no sensible collision resolution. All to the endpoint of issuing an invitation to intrude into private spaces. Bleah.
- [16:47] * arjen is taking notes as well ...
- [16:47] dgp The main positive value of the routine Tcl_RegisterObjType()....
- [16:47] dgp ... is that it is a routine name by which you can call up the man page that documents the Tcl_ObjType interface.