Tcl Source Code

View Ticket
Login
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: