new CONSTification of Tcl 8.4 (help) 
Author Message
 new CONSTification of Tcl 8.4 (help)

Hi guys, now that the new CONST tip has been applied to TCL, my oratcl
extension compiles with warnings.  I expected this.  Is there a defining
moment in tcl.h that would tell me to

#ifdef IHAVEBEENCONSTED
        use the new prototype
#else
        use the old prototype
#endif

Should I just use TCL_MAJOR.. = 8 and ..MINOR == 4

Todd

--
Todd M. Helfter
Database Analyst/Programmer
Purdue University



Sat, 24 Jul 2004 21:36:20 GMT  
 new CONSTification of Tcl 8.4 (help)

Quote:

> Hi guys, now that the new CONST tip has been applied to TCL, my oratcl
> extension compiles with warnings.  I expected this.  

Hi Todd.  Thanks for your efforts to update Oratcl.

The TIP 27 changes may be in a state of flux right now.  There have
been concerns raised in the Tcl'ers chatroom that the changes in the
current HEAD place too large a burden on the authors of existing
extensions.  There are two points at issue.

1) The new treatment of Tcl_DString's as black boxes.
2) The source incompatibility in the (char **) => (CONST char**)
   conversion.

That said, my current advice working with the current HEAD of Tcl is,
if you have existing code that compiles with Tcl 8.3 headers, then just
add -DUSE_NON_CONST to enable compiling with Tcl 8.4 headers.  Any
remaining warnings you should be able to clear up in a manner consistent
with both versions.  For an example see Patch 511035 in the incrtcl
project at SourceForge.

Eventually, when you want to leave behind support for Tcl 8.3 and
earlier and require 8.4 or later for use of your extension (to use
all the great new features!), then you can convert to using the
8.4+ CONST interface exclusively.

--
| Don Porter          Mathematical and Computational Sciences Division |

| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



Sun, 25 Jul 2004 00:14:22 GMT  
 new CONSTification of Tcl 8.4 (help)

Quote:

>The TIP 27 changes may be in a state of flux right now.  There have
>been concerns raised in the Tcl'ers chatroom that the changes in the
>current HEAD place too large a burden on the authors of existing
>extensions.  There are two points at issue.

>1) The new treatment of Tcl_DString's as black boxes.

This one is new to me -- is there a TIP discussing this change?

--Joe English




Sun, 25 Jul 2004 09:51:41 GMT  
 new CONSTification of Tcl 8.4 (help)

Quote:


>> The TIP 27 changes ...
>> 1) The new treatment of Tcl_DString's as black boxes.

> This one is new to me -- is there a TIP discussing this change?

Uhhhh... 27?

A bit more seriously, TIP 27 says that when a Tcl function returns a
(char *) that points to an internal field of a Tcl data structure,
it should be changed to return a (CONST char *) so it is clear, and
the compiler will enforce, that callers are not to directly modify
that field.

Comments in tcl.h indicate that the "string" field of a Tcl_DString
struct is just such a field, not meant for callers to modify.  So
several Tcl routines that returned (char *)s pointing into Tcl_DString
structs were changed to return (CONST char *) instead.  

It's becoming apparent that, those comments notwithstanding,
Tcl_DStrings have been used in several places as scratch space "owned
by" and directly written on by the caller.  So, my mind is open to
reconsidering those changes.

--
| Don Porter          Mathematical and Computational Sciences Division |

| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



Sun, 25 Jul 2004 13:08:52 GMT  
 new CONSTification of Tcl 8.4 (help)

Quote:

> A bit more seriously, TIP 27 says that when a Tcl function returns a
> (char *) that points to an internal field of a Tcl data structure,
> it should be changed to return a (CONST char *) so it is clear, and
> the compiler will enforce, that callers are not to directly modify
> that field.

> Comments in tcl.h indicate that the "string" field of a Tcl_DString
> struct is just such a field, not meant for callers to modify.  So
> several Tcl routines that returned (char *)s pointing into Tcl_DString
> structs were changed to return (CONST char *) instead.

> It's becoming apparent that, those comments notwithstanding,
> Tcl_DStrings have been used in several places as scratch space "owned
> by" and directly written on by the caller.  So, my mind is open to
> reconsidering those changes.

Don,

I strongly urge you to reconsider. I regard the comment in tcl.h as disingenuous.

Tcl_DStringSetLength allows you to grow/shrink a Tcl_DString's length
to whatever size you want. Why allow growing (or shrinking for that matter)
of a Tcl_DString if you can't changes bytes in it directly?

I always thought Tcl_DStringLength existed specifically to allow
Tcl_DStrings to be used (as you put it) as "scratch space" by the caller.

The main use being, to make it easy for
C-extensions to construct return values for Tcl_Interp's by:

        1) calling Tcl_DStringSetLength(dsPtr, len) to size a dsPtr as desired.

        2) calling a 3rd party c or extension-specific
        function that uses Tcl_DStringValue(dsPtr) and Tcl_DStringLength(dsPtr)
        as output parameters.

        3) Calling Tcl_DStringResult(interp, dsPtr) before returning

Making Tcl_DStrings 'complete black boxes' forces one to resort to
using lower level functions instead to do this kind of processing.
To me that seems to be a significant step backwards in functionality and ease
of use when it comes to C-extension writing.

-mike

- Show quoted text -

Quote:
> | Don Porter          Mathematical and Computational Sciences Division |

> | http://math.nist.gov/~DPorter/                                  NIST |



Sun, 25 Jul 2004 14:13:22 GMT  
 new CONSTification of Tcl 8.4 (help)

Quote:



>>> The TIP 27 changes ...
>>> 1) The new treatment of Tcl_DString's as black boxes.

>> This one is new to me -- is there a TIP discussing this change?

>Uhhhh... 27?

:-)

There was no specific mention of Tcl_Dstrings in TIP 27,
I was just wondering if there were some change to the Tcl_DString
interface in the works.

Quote:
>Comments in tcl.h indicate that the "string" field of a Tcl_DString
>struct is just such a field, not meant for callers to modify.  So
>several Tcl routines that returned (char *)s pointing into Tcl_DString
>structs were changed to return (CONST char *) instead.

So this isn't about Tcl_DStrings _per se_, just certain
core routines that happen to use Tcl_DStrings for storage
management?  Sorry for being obtuse.

--Joe English




Mon, 26 Jul 2004 00:12:52 GMT  
 new CONSTification of Tcl 8.4 (help)

Quote:

> There was no specific mention of Tcl_Dstrings in TIP 27,

Right.  TIP 27 has guidelines, not a To-Do list.

Quote:
> I was just wondering if there were some change to the Tcl_DString
> interface in the works.

A few Examples:  What was
    char * Tcl_DStringAppend(Tcl_DString *, CONST char *, int);
    char * Tcl_GetCwd(Tcl_Interp *, Tcl_DString *);
in Tcl 8.3 are now
    CONST char * Tcl_DStringAppend(Tcl_DString *, CONST char *, int);
    CONST char * Tcl_GetCwd(Tcl_Interp *, Tcl_DString *);
in the current HEAD revision.

I'm currently reconsidering both changes and others.

Quote:
> So this isn't about Tcl_DStrings _per se_, just certain
> core routines that happen to use Tcl_DStrings for storage
> management?  

Exactly the opposite.  If it were only the core that made use of
direct writing to Tcl_DString's internals, I'd just change the core.
The issue is that a significant amount of third-party code does
this, and keeping these particular CONST-ifications would break
their code.

The lesson drawn is that Tcl_DStrings are really white-box structures,
just like Tcl_Obj's.

--
| Don Porter          Mathematical and Computational Sciences Division |

| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



Mon, 26 Jul 2004 01:07:28 GMT  
 new CONSTification of Tcl 8.4 (help)

Quote:
>> It's becoming apparent that, those comments notwithstanding,
>> Tcl_DStrings have been used in several places as scratch space "owned
>> by" and directly written on by the caller.  So, my mind is open to
>> reconsidering those changes.

> I strongly urge you to reconsider.

And so I have.  In the current HEAD of the Tcl/Tk development sources,
the following routines will continue to return (char *) pointers that
point into a Tcl_DString, just as they do in Tcl 8.3:

        Tcl_DStringAppend
        Tcl_DStringAppendElement
        Tcl_JoinPath
        Tcl_TranslateFileName
        Tcl_ExternalToUtfDString
        Tcl_UtfToExternalDString
        Tcl_UniCharToUtfDString
        Tcl_GetCwd
        Tcl_WinTCharToUtf       (Windows only)

Also, Tcl_WinUtfToTChar will return (TCHAR *) (Windows only) and
Tcl_UtfToUniCharDString will return (Tcl_UniChar *).

Quote:
> I regard the comment in tcl.h as disingenuous.

That's changed too.

--
| Don Porter          Mathematical and Computational Sciences Division |

| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



Tue, 27 Jul 2004 10:51:51 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Is there a new Tcl/Tk 8.4 Roadmap?

2. Tcl 8.4 new command design

3. ISO: Help regarding Tcl/Tk 8.4 Japanese Input Methods

4. Tcl 8.4 Version Help

5. Install tcl 8.4 error, Can't find a usable init.tcl in the following directories

6. Tcl SOAP - Tcl 8.4?!?!?! (Immediate Need)

7. Tcl 7.4 to Tcl 8.4 porting issues

8. Stubs with Tcl 8.3 vs Tcl 8.4

9. CONST Tcl 8.3 vs Tcl 8.4

10. OpenGL Bindings for Tcl/Tk 8.4

11. problem about tcl 8.3 and 8.4

12. Problem compiling TCL 8.4 on HP-UX 11

 

 
Powered by phpBB® Forum Software