Posted to tcl by jima at Wed May 14 07:48:44 GMT 2014view raw

  1. [16:28] dgp general advice: do not use Tcl_ConvertToType()
  2. ...
  3. [16:33] * jima thanks dgp for the advice... the crash was due me not initializing an extension properly
  4. [16:34] dgp yes, so now you're in the situation I feared you would be in.
  5. ...
  6. [16:34] dgp Fixed the segfault, but still using T_CTT().
  7. [16:35] jima yes, still use T_CTT was called in code depending on the extension
  8. [16:35] jima the extension is VecTcl ... and it relies in type conversion to deal with lists <=> arrays
  9. [16:35] jima (I think)
  10. [16:35] hypnotoad In general, you recommend making a copy with "Tcl_XXXFromObj()"?
  11. [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.
  12. [16:36] jima not me, Christian
  13. [16:36] hypnotoad
  14. [16:36] jima unluckily he does not come to the chat (yet...)
  15. [16:36] emiliano wanders in.
  16. ...
  17. [16:36] jima I am just trying to use his extension
  18. [16:37] jima in conjunction with another one coming from Arjen...
  19. [16:37] jima (having fun these days)
  20. [16:37] hypnotoad I just ask because I am working on an extension that create native Tcl_Objs for geometry constructs and vectors
  21. [16:37] dgp So what intrep intrusions is VecTcl guilty of then?
  22. [16:38] jima https://github.com/auriocus/VecTcl
  23. [16:38] jima is the home of the extension
  24. [16:38] jima I am following https://github.com/auriocus/VecTcl/blob/master/APIdemo/generic/lsvd.c
  25. [16:38] jima this particular piece
  26. [16:38] jima /* Convert the 1st argument to VecTcl object */
  27. NumArrayInfo *info = NumArrayGetInfoFromObj(interp, matrix);
  28. if (!info) { return TCL_ERROR; }
  29. [16:39] jima calls it
  30. [16:39] <awb> exits, stage left!
  31. [16:39] dgp not at that link
  32. [16:40] jima /* Extract the NumArrayInfo* from a Tcl_Obj
  33. * If naObj can't be converted to NumArray,
  34. * NULL is returned */
  35. NumArrayInfo *NumArrayGetInfoFromObj(Tcl_Interp *interp, Tcl_Obj* naObj) {
  36. if (Tcl_ConvertToType(interp, naObj, VecTclNumArrayObjType) != TCL_OK) {
  37. return NULL;
  38. }
  39.  
  40. return naObj -> internalRep.twoPtrValue.ptr2;
  41. }
  42. [16:41] emiliano exits, stage left!
  43. [16:41] jima At https://github.com/auriocus/VecTcl/blob/master/generic/vectclapi.c
  44. [16:41] dgp ok, that's fairly harmless.
  45. [16:41] jima yes
  46. [16:41] jima the mistake was totally on my side
  47. [16:42] jima I lacked a VecTcl_InitStubs call
  48. [16:42] dgp better would be to call the "SetFromAny proc direct.
  49. [16:42] dgp T_CTT() just obfuscates things.
  50. [16:43] * jima noted
  51. [16:43] * hypnotoad also noted
  52. [16:43] dgp I think experience has shown....
  53. [16:44] dgp ....that it's best for a Tcl_ObjType author *not* to call Tcl_RegisterObjType()....
  54. [16:44] hypnotoad Oh?
  55. [16:44] dgp ...but instead to provide a My_GetFooFromObj() routine.
  56. [16:44] dgp objtype registration is an error wrapped in a mistake.
  57. [16:45] hypnotoad Well that makes my job easier...
  58. [16:45] tpoindex is feeling chatty!
  59. [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.
  60. [16:47] * arjen is taking notes as well ...
  61. [16:47] dgp The main positive value of the routine Tcl_RegisterObjType()....
  62. [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.
  63.