|
From: Daniel A. S. <da...@us...> - 2010-02-16 18:41:05
|
On Feb 15, 2010, at 22:56, nij...@us... wrote: > Update of /cvsroot/tcl/tcl/tools > In directory sfp-cvsdas-2.v30.ch3.sourceforge.com:/tmp/cvs-serv22621/tools > > Modified Files: > genStubs.tcl > Log Message: > reverted earlier rename from tcl*Stubs to > tcl*ConstStubs, it's not necessary at all. On Feb 5, 2010, at 20:53, nij...@us... wrote: > Eliminate the need for an extra Stubs Pointer > for adressing a static stub table: Just change > the exported table from static to MODULE_SCOPE. for the record, these were actually quite deliberate changes and part of the overall "const stubs tables" and "tclStubsPtr out of libtcl.so" efforts which were discussed at some length on email & chat back in 2007. the intent behind the name change was to uncover any accidental use of the private (implementation detail) tcl*Stubs symbols outside of tclStubInit.c and Tcl_CreateInterp() resp. TclTommath_Init() (note that MODULE_SCOPE is not guaranteed to be effective on unix platforms, e.g. it has no effect with older gcc or non-gcc compilers, so accidental use of these exported symbols is quite possible) I've been out of the loop for the last few months, so I'll assume that these reversals are being made for sound reasons and have been equally widely discussed, just wanted to note the background behind the original change... Now back to our regular programming on the exciting world of hash functions ;-) |
|
From: Jan N. <nij...@us...> - 2010-02-16 20:43:17
|
2010/2/16 Daniel A. Steffen <da...@us...>:
>> reverted earlier rename from tcl*Stubs to
>> tcl*ConstStubs, it's not necessary at all.
>
> On Feb 5, 2010, at 20:53, nij...@us... wrote:
>
>> Eliminate the need for an extra Stubs Pointer
>> for adressing a static stub table: Just change
>> the exported table from static to MODULE_SCOPE.
>
> for the record, these were actually quite deliberate changes and part of the overall "const stubs tables" and "tclStubsPtr out of libtcl.so" efforts which were discussed at some length on email & chat back in 2007.
Don't worry, I didn't revert any of those deliberate original
changes. However, making all stub tables static, and then
use an extra pointer to make the main stub table accessible
was rather clumsy. Therefore I extended genStubs.tcl to find
out which one is intended to be exported. It's a simplification,
retaining the original idea. In that process, I changed the name
of the stub table symbols, later discovering that that was
not necessary at all. So I reverted part of my own later changes.
Regards,
Jan Nijtmans
|
|
From: Daniel A. S. <da...@us...> - 2010-02-16 22:29:42
|
On Feb 16, 2010, at 12:43 PM, Jan Nijtmans wrote: > 2010/2/16 Daniel A. Steffen <da...@us...>: >>> reverted earlier rename from tcl*Stubs to >>> tcl*ConstStubs, it's not necessary at all. >> >> On Feb 5, 2010, at 20:53, nij...@us... wrote: >> >>> Eliminate the need for an extra Stubs Pointer >>> for adressing a static stub table: Just change >>> the exported table from static to MODULE_SCOPE. >> >> for the record, these were actually quite deliberate changes and part of the overall "const stubs tables" and "tclStubsPtr out of libtcl.so" efforts which were discussed at some length on email & chat back in 2007. > > Don't worry, I didn't revert any of those deliberate original > changes. However, making all stub tables static, and then > use an extra pointer to make the main stub table accessible > was rather clumsy. Therefore I extended genStubs.tcl to find > out which one is intended to be exported. It's a simplification, > retaining the original idea. In that process, I changed the name > of the stub table symbols, later discovering that that was > not necessary at all. So I reverted part of my own later changes. well, no... the name of the MODULE_SCOPE symbols used by Tcl_CreateInterp() and TclTommath_Init() before your latest changes were tclConstStubsPtr and tclTomMathConstStubsPtr. Now they are tclStubs and tclTomMathStubs, which is back to what they were in 2008 before [Patch 1938497] went in, c.f. http://tcl.cvs.sourceforge.net/viewvc/tcl/tcl/generic/tclStubInit.c?r1=1.152&r2=1.153 http://tcl.cvs.sourceforge.net/viewvc/tcl/tcl/generic/tclBasic.c?r1=1.296&r2=1.297 again the intent was (in particular for tclStubs) to have an _different_ exported name from before [Patch 1938497] to allow detection of inadvertent external use of these symbols in cases where MODULE_SCOPE is not effective. |
|
From: Joe E. <jen...@fl...> - 2010-02-17 05:49:57
|
Jan Nijtmans wrote: > OK, thanks! Well, this revertion was in fact my attempt of > streamlining genStubs.tcl > with ttkGenStubs.tcl ([2010-02-05]), but this was together with more > const-changes, which were reverted by Joe the same day. The name change > from ttk*Stubs to ttk*ConstStubs in my patch were reverted as well in > this commit. > > My impression was that the important symbols which caused problems in the > past were tcl*StubsPtr, the same one initialized by the stub library: Having > the same symbol in libtcl.so as in libtclstub.a, that's the problematic thing > > However, the tclStubs symbol is not present in libtclstub.a, and in > addition, this symbol is made "const" now, so I don't think it can > cause any problem any more. Besides, it's only the main stub table > that's MODULE_SCOPE, the others are still static. tclStubs (the record) has never been present in libtclstub.a. The stub library has only ever contained definitions for tclStubsPtr (the pointer), Tcl_InitStubs (the routine that initializes the pointer) and various support machinery. The tclStubs record has always been defined in the main library libtcl. Libtcl *used* to contain a second copy of tclStubsPtr (the pointer) and Tcl_InitStubs(). This was never necessary, was mostly harmless on most systems, but caused problems on others, which was why it was removed. The rule has always been: if you compile with -DUSE_TCL_STUBS, you must link with the stub library; if you compile without -DUSE_TCL_STUBS, you must link with the main library. Because historically libtcl contained a redundant second copy of tclStubsPtr and Tcl_InitStubs(), many build systems were able to work even when they didn't follow those rules. Removing the second redundant copy of tclStubsPtr from the main library caused those build systems to break, but it fixed things on platforms where the second redundant copy caused problems, which is why that was done. I don't know where all the extra Consts came from or why they were seen as necessary. The tile/ttk stub table pointer has always been declared 'const'. The stub table record lacks a const qualifier because it is passed to Tcl_PkgProvideEx(), which takes a "void *" (note no const). > However, I'm fine with changing the symbol names back to > (tcl|tk|ttk)*ConstStubs. Joe, can you agree with that? As long as you don't add any contravariant const qualifiers. I reverted the changes that caused compilation failures when compiled under 8.4. As noted in the commit message, Tile needs to work with 8.4 and I'd really prefer if the codebases could be kept relatively in sync. --Joe English jen...@fl... |