Tcl Source Code

There are several prototypes that formerly in 8.3 returned 
char * values.  One example is Tcl_SetVar2.  

They now return CONST char * values.   This should be 
CONST84 char * so that extension writers can define
USE_NON_CONST.  

--gah

Logged In: YES 
user_id=80530

fixed by acceptance of Patch 585105.

Logged In: YES 
user_id=80530

see also Patch 585105.

File Added - 27096: tkconst.patch

Logged In: YES 
user_id=80530


Here is a companion patch for Tk.

File Added - 27089: const.patch

Logged In: YES 
user_id=80530


Here's a patch that addresses the issue.

Apply the patch, `make genstubs`, and install.
The resulting headers will be configurable 
like so:

#define USE_NON_CONST

will disable all new CONSTs that cause any
kind of source incompatibility with Tcl 8.3.
This is the "#define & go" option.

#define USE_COMPAT_CONST

this does what USE_NON_CONST
used to do -- disables only those new
CONSTs that would otherwise force
one to support only 8.4 and up.

With neither of those defined, the
header will supply the documented
Tcl 8.4 interfaces.

The patch also CONSTifies a few more
APIs -- notably the Tcl_CmdProc typedef.
Now that USE_NON_CONST offers a way
to completely avoid the changes, there's no
reason to delay the really tough one.

Note that Tk, like other extensions,
will need modifications to use the
features of this patch.

Please try and comment.

Logged In: YES 
user_id=137748

Unfortunately it's counterproductive. 
It causes extensions to drop support of 8.4 (or more 
accurately, people won't take the time to make them
compile with 8.4).  It's too bad that source code 
compatibility isn't as valued as binary compatibilty.  
That's what CONST84 is supposed to prevent.

--gah

Logged In: YES 
user_id=80530


That's just not what USE_NON_CONST / CONST84 is for.

CONST84 exists to disable only those new CONSTs that
would otherwise force extensions to drop (compiling) 
support for pre-8.4 Tcl, because compilers do not know
how to convert a (char **) to a (const char **).
USE_NON_CONST allows for support for both 8.3
and 8.4 headers until a package naturally wants to
require 8.4 because it is using 8.4 features.

Tcl routines that now return (CONST char *) where
they previously returned (char *) do not need such a
mechanism, because compilers do know how to
convert (char *) values into (const char *) values.
This means that extensions can update their code
to compile with both 8.3 and 8.4 headers, and
that's what they're expected to do to begin
supporting Tcl 8.4.

Tcl 8.4 does not offer a "#define and go" migration
option for dealing with the CONST-ification changes.
At a minimum, extensions must deal with the source
incompatibility approved by TIP 27.

It's possible that such a "#define and go" option could be
provided, but it would need to be something new, not a
dual meaning imposed on CONST84.  I'd rather not
go that way, but it is possible.

Logged In: YES 
user_id=137748

Adding const in the caller's code cacades changes
throughout. Either one
wants to use const everywhere or they don't.  There's no
middle ground.

This is a nuisance for everyone trying to port old code to
8.4.  What's
the issue for not using CONST84 instead?  

--gah

Logged In: YES 
user_id=80530


The CONST84 macro is tied only to those
changes that cannot be reconciled.  The
return of a CONST char * where a char *
was returned before can be reconciled by
adding "const" in the caller, so that the
modified code compiles with both 8.3
and 8.4 headers.

This type of source incompatibility
was approved in TIP 27.