Improve Tcl 8.7/9.0 readiness, `const` usage

[chrstphrchvz]

Tcl_GetObjType() returns const as of Tcl 8.6, and Tcl.xs never modifies these structs

[chrstphrchvz]

In order to test changes in Tcl::pTk for supporting Tk 8.7, I would like get Tcl.pm to build and run with Tcl 8.7/9.0. I am going to repurpose this pull request to include other changes which I believe will be needed:

• Tcl.xs assumes tcl.h always defines the STRINGIFY()/JOIN() macros, but in Tcl 9.0 (and Tcl 8.7 with -DTCL_NO_DEPRECATED) they are normally not defined:

  /usr/lib/perl5/5.34/core_perl/CORE/perl.h:4904:33: error: expected ‘)’ before ‘STRINGIFY’
   4904 | #define PERL_API_VERSION_STRING STRINGIFY(PERL_API_REVISION) "." \
        |                                 ^~~~~~~~~

  The definitions of STRINGIFY()/JOIN() in tcl.h have been guarded by #ifndef since Tcl 8.4b2, and identical to the definitions in Perl. I believe it is okay for Tcl.xs to rely on Perl's definitions for them and not #undef them before including tcl.h.

• Due to Tcl TIP 543, tcl.h no longer defines TCL_INTERP_DESTROYED in Tcl 9.0 (and Tcl 8.7 with TCL_NO_DEPRECATED defined):

  Tcl.xs:1873:56: error: ‘TCL_INTERP_DESTROYED’ undeclared (first use in this function); did you mean ‘TCL_TRACE_DESTROYED’?
   1873 |         newCONSTSUB(stash, "INTERP_DESTROYED", newSViv(TCL_INTERP_DESTROYED));
        |                                                        ^~~~~~~~~~~~~~~~~~~~

  Existing code relying on TCL_INTERP_DESTROYED should instead check Tcl_InterpDeleted(). It is trivial to wrap Tcl_InterpDeleted() in Tcl.xs. I am not aware of any Tcl.pm users currently relying on Tcl::INTERP_DESTROYED, but if there are they can migrate to checking $interp->InterpDeleted(). I am not aware of why this method is useful, particularly from Tcl.pm. I have not created a test for the new method, but I have verified that its return value is correct for a hacked version of Tcl_InterpDeleted().

[vadrer]

ok, nice. thanks!

[chrstphrchvz]

I am trying to figure out how to properly deal with various types (int, wideInt, boolean, bytearray) no longer being registered in Tcl 9.0. This causes Tcl_GetObjType() to return NULL, which breaks SvFromTclObj() since it assumes cached type pointers are not NULL so that values with objPtr->typePtr == NULL fall through to the string case. Example: in disposal-subs-b.t, flush_afters() waits for after info to be empty, but SvFromTclObj() returns a garbage integer value instead of an empty list, and the test never exits. I wonder if SvFromTclObj() should more resemble Tkinter’s approach which checks for objPtr->typePtr == NULL first (see FromObj() in _tkinter.c; I am not aware of Tkinter having already prepared for Tcl 8.7/9.0, though).

I am also considering how to deal with Tcl TIP 484 which removes the wideInt type, meaning the int type is used for 64-bit values even on 32-bit platforms. I am not aware of a good approach for use in XS libraries to support 64-bit integer SVs. Currently I would be inclined to return a Tcl integer as a string unless it is within [IVMIN,UVMAX] (or maybe as an NV if within the range of double which can represent odd integers).

It sounds like upstream Tcl may be willing to help C API users migrate, as there are not very many which are still actively maintained (edit: see https://core.tcl-lang.org/tcl/info/3bb3bcf2da5b).

[chrstphrchvz]

I am satisfied enough with the work in this pull request for it to be merged.

There is at least one remaining issue where Tcl.pm built to use stubs will not load with Tcl 9.0 (Tcl_InitStubs() cannot be called with a differing major version), but I am currently not interested in fixing this.