Posted to tcl by jima at Wed May 14 07:48:44 GMT 2014view pretty
[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.