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