|
From: Jan N. <nij...@us...> - 2008-11-17 11:16:18
|
2008/11/17 Andreas Leitgeb <av...@lo...>:
> I don't know, if Tcl_SetResult has still any value apart from
> compatibility. If it has, then it might be worth a consideration
> adding a variant like "Tcl_SetResultRO"(bikeshed-warning) that will
> take a const char*, and a pointer to a function that in turn will
> also take a const-pointer. That means, there'd also be a
> typedef void (Tcl_FreeProcRO) _ANSI_ARGS_((const char *blockPtr));
> and TCL_STATIC would be eventually be typed as Tcl_FreeProcRO, so
> it could be passed to the const char* taking Tcl_SetResultRO().
A free of a const pointer? That looks wrong to me.
> This appears to me to avoid the "lying to the compiler", by splitting
> up the Tcl_SetResult into one for the const-cases and one for general
> cases. Anyone who cares about the compiler warnings (hopefully
> including the core) could then use the appropriate one, if creating
> a TclObject and using the "Obj" variant is not desired..
The vast majority of calls use 0 or TCL_VOLATILE, and that's
the CONST case. So we could reserve Tcl_SetResult for
the CONST case and force to use Tcl_SetObjResult in
the other cases. That would already be a lot less work
than modify all Tcl_SetResult calls in the core.
> It may of course be, that if one changes a source at all, he should
> really change it to the "Obj" variant and also make sure that he doesn't
> use interp->result, and also clean up all further legacy-stuff here and
> there in the course... That would of course void my suggestion, but
> possibly be too much work for old code to be reasonable.
Yes, it's a lot of work. Thanks for your reaction.
Regards,
Jan Nijtmans
|