Re: Possible bug in Tcl.pm exposed by Tktable?

[email protected] (Christopher Chavez) Wed, 1 Apr 2020 15:29:20 -0500
Newsgroups perl.tcltk
Message-ID <[email protected]>
On 4/1/2020 7:19 AM, Konovalov, Vadim wrote:
>> A Tcl::pTk user opened
>> a ticket observing this issue in the
>> test suite:
>> https://rt.cpan.org/Ticket/Display.html?id=3D132278
>
> Can you open the ticket on Tcl.pm, given that we see that it is
> more relevant here?

I have moved the existing ticket to keep the reporter informed.
I meant to adjust the title as well but couldn't do so once it moved.


>> But this would appear to assume the program writer is/should be
>> in control of compiling and packaging everything in their program.
>> It is not possible to do this when intending for Tcl.pm reuse
>> existing Tcl or Perl installations, such as from package managers.
>
> IMO linker will use your function, if you redefine it in your code > and=
 will pass it sooner to linker.
> So  you can "neutralize" freeing  environment variables in libtcl
>
> IOW Tcl.xs should redefine Tcl_PutEnv to "forward" this into perl's
> environment call - what is it?
> According to https://perldoc.perl.org/5.30.0/perlclib.html#_stdlib.h_-fu=
nctions
> - this is my_setenv?

Interesting, this is something I'm not familiar with.

I have also neglected to consider if other Tcl wrappers (Python, Ruby)
are affected and whether they may have already solved the same problem.

> I will work on the fix, when time permits

Thanks. Indeed there should be no rush to fix this. It is a benign issue
that might only pose a minor annoyance to users (e.g. "Your program
has crashed, report it?" nags from OS); unsaved data does not appear
to be in jeopardy because of it.


Christopher A. Chavez