Ticket UUID: | 3007895 | |||
Title: | Tcl_(Find|Create)HashEntry stub entries can never be called | |||
Type: | Bug | Version: | None | |
Submitter: | nijtmans | Created on: | 2010-05-27 11:00:38 | |
Subsystem: | 10. Objects | Assigned To: | nijtmans | |
Priority: | 9 Immediate | Severity: | ||
Status: | Closed | Last Modified: | 2011-01-01 00:20:55 | |
Resolution: | Fixed | Closed By: | nijtmans | |
Closed on: | 2010-12-31 17:20:55 | |||
Description: |
From tcl.h we can see that Tcl_(Find|Create)HashEntry is a macro, but it is in the stub table as well. The macro overrides the definition in tclDecls.h: ========================================= #undef Tcl_FindHashEntry #define Tcl_FindHashEntry(tablePtr, key) ... #undef Tcl_CreateHashEntry #define Tcl_CreateHashEntry(tablePtr, key, newPtr) ... ========================================= So, the stub table entries are useless. The only effects it has is: - Need tricks like #undef, to make tclHash.c and tclInitStubs.c compile. - Tcl_(Find|Create)HashEntry could be static in tclHash.c, but only for the stub table they are made EXTERN Solution: remove those two functions from the stub table, and we can remove all remaining trickery. | |||
User Comments: |
nijtmans added on 2011-01-01 00:20:55:
allow_comments - 1 Backported to 8.5: Now the Tcl_(Find|Create)HashEntry functions do exactly the same as the Tcl_(Find|Create)HashEntry macro's, so at least the confusion addressed in this issue is gone. nijtmans added on 2010-08-23 01:22:42: Here is a better patch, which does the same as the previous one, but restores the two functions having the same signature and behavior as the macros. Still, the stub entries are useless, but at least there is an option now to remove the macros and still having everything work as before. nijtmans added on 2010-08-23 01:20:03: File Added - 384222: hash.patch nijtmans added on 2010-08-23 01:15:41: File Deleted - 375339: nijtmans added on 2010-08-19 23:06:14: There is another option: We could keep the stub table entries, but make the signature match the doc again. That would be OK to me too. dgp added on 2010-08-17 00:40:05: Aim of the patch was to move toward a revised hash table implementation. The change was a binary incompat, though, so it was disabled with #ifdef TCL_PRESERVE_BINARY_COMPATIBILITY. Sometime in Tcl 8.5 development, the new maintainers concluded that preserving binary compat was one of the things Tcl 8.* development was commited to, so dragging around code never to be enabled was no longer worth doing. So now we still have stub table entries that support only a configuration we removed in the last minor release. Seems like they can go away. Probably best we make the change on in 8.6 development and delay or forgo any changes to tcl.decls in 8.5.* dgp added on 2010-08-17 00:30:46: To reclaim that patch, cvs -D 2000-07-21 -D 2000-07-22 in tcl/generic dgp added on 2010-08-17 00:23:41: The stub table entries were added: 2000-07-21 Eric Melski <[email protected]> * generic/tclStubInit.c: * generic/tclObj.c: * generic/tclInt.h: * generic/tclHash.c: * generic/tclDecls.h: * generic/tcl.h: * generic/tcl.decls: * doc/Hash.3: Reapplied patch from Paul Duffin to extend hash tables to allow custom key types, such as Tcl_Obj *'s, and others. nijtmans added on 2010-08-16 23:24:40: Why priority 9? If it's only because you want this to be on the top of your list, OK! Besides that, it's only about the removal of dead code, so I don't see the need for prio 9. nijtmans added on 2010-05-28 17:22:21: OK, Miguel? dkf added on 2010-05-27 20:44:35: Just leave it alone, Jan. You're not the area maintainer. nijtmans added on 2010-05-27 18:05:45: Another benifit: Making Tcl_(Find|Create)HashEntry static means that the dynamic loader has two less symbols which need to be resolved. nijtmans added on 2010-05-27 18:02:30: File Added - 375339: hash.patch |
Attachments:
- hash.patch [download] added by nijtmans on 2010-08-23 01:20:03. [details]