Ticket UUID: | 402561 | |||
Title: | Fix for bug 123153 | |||
Type: | Patch | Version: | None | |
Submitter: | andreas_kupries | Created on: | 2000-11-28 11:02:19 | |
Subsystem: | 10. Objects | Assigned To: | andreas_kupries | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2001-04-05 07:08:30 | |
Resolution: | Accepted | Closed By: | dgp | |
Closed on: | 2001-04-05 00:08:30 | |||
User Comments: |
andreas_kupries added on 2001-01-19 20:28:47:
Committed. dgp added on 2001-01-18 06:53:32: Patch Code - Modified - New Version Since the macro Tcl_InitHashTable has been restored (when TCL_PRESERVE_BINARY_COMPATIBILITY is not set) the #undef Tcl_InitHashTable (line 145 of generic/tclHash.c) must be restored as well. New patch uploaded making that change. With that change, I think this patch can be applied. It fixes the reported bug. Depending on how discussions on TCLCORE are resolved, we may want to make further changes. I'm not a big fan of this TCL_PRESERVE_BINARY_COMPATIBILITY macro. It just invites the existence of yet another incompatible variant of Tcl out there for extension writers to have to worry about. If the TCT establishes that we simply won't allow binary incompatibility except at major version increments, then tests for truth of TCL_PRESERVE_BINARY_COMPATIBILITY could all be replaced with tests that TCL_MAJOR_VERSION >= 9, or the incompatible code could just be removed completely from the 8.x development branch. There no need to make the availability of a fix for Bug 123153 in CVS wait for a resolution of that matter though. Nice work, Andreas, improving the flow of the man page. andreas_kupries added on 2001-01-17 03:41:32: Patch Code - Modified - New Version andreas_kupries added on 2001-01-17 03:40:03: Patch Code - Modified - New Version andreas_kupries added on 2001-01-16 13:34:08: Patch Code - Modified - New Version andreas_kupries added on 2001-01-16 13:26:43: Patch Code - Modified - New Version andreas_kupries added on 2001-01-16 13:26:12: Patch Code - Modified - New Version dgp added on 2000-12-21 23:47:39: Patch Code - Modified - New Version The patch did not apply clean to the CVS HEAD, partly due to end-of-line translations, and partly because it looks like a diff from an earlier state of the sources. I think using `cvs diff -c` to generate patches works better. After applying the patch and cleaning up, there were still references to Tcl_InitHashTableEx() in doc/Hash.3, generic/tclHash.c, generic/tclObj.c, and unix/mkLinks. The reference in generic/tclObj.c causes a link failure when trying to build the patched sources. On line 145 of the patched generic/tclHash.c, was there still any reason to keep the #undef Tcl_InitHashTable ? I assumed there wasn't, and have removed it. The revised patch corrects these problems and updates the ChangeLog message to reflect these additions. One other issue I did not revise is the documentation. After patching, doc/Hash.3 still claims: Tcl_InitHashTable calls the extended function Tcl_InitExtendedHashTable with a NULL typePtr. but that's no longer true since the macro has been removed, right? Please correct that, or explain to me why it is still correct. andreas_kupries added on 2000-12-21 16:21:58: Patch Code - Modified - New Version The forgotten changes to doc/Hash.3 are now part of the (revised) patch. dgp added on 2000-12-21 03:24:06: This patch is missing changes to doc/Hash.3 to document the new public function. Maybe that's because of the indecision on the name? My vote is to change the name to Tcl_InitExtendedHashTable(). I agree we should aim for getting rid of all the *Ex() stuff in the long run, so why keep one now when we aren't forced to do so by compatibility with a prior stable release? Add the docs and I'll approve integration. andreas_kupries added on 2000-12-20 15:52:17: Although I would like to see the *Ex functions exterminated I also have not that big an attachment to this part of the patch that makes me unable to drop it. I am willing to leave this hunk out (now), but would also log a request to cleanup the mess with the 'Ex'es for Tcl 9. hobbs added on 2000-12-10 09:24:31: Is the aesthetic change of Tcl_InitHashTableEx to Tcl_InitExtendedHashTable really necessary? As the comment notes, the use of Tcl_*Ex is ubiquitous, even if many hate it due to its overuse by Windows. At least people understand it. |
Attachments:
- None [download] added by andreas_kupries on 2000-11-28 18:02:19. [details]