Re: [TCLCORE] Support ANSI C

[Benjamin R. <Ben...@ep...>]

Hi Markus,


[Anybody please correct me if I get any facts wrong here.]


"SF Markus Elfring" <el...@us...> writes:
> I see that a lot of old style function signatures are used in the C
> source files.

A lot of the Tcl source is *old*.  IOW, it has stood the test of time.

AFAIK, compiling Tcl today requires an ISO C compiler, because it uses
ISO C syntax in a few places.  Some 13 years after the standard was
published, it's probably not too much to assume that a usable platform
has such a compiler.

OTOH having a compliant library is a different matter, there are
probably a number of systems still around with operating systems on
them that were abandoned by their original authors.  I guess most of
them can still support GCC, so you have an ISO C compiler proper, but
you don't necessarily have an ISO C compliant library.  This means
that the compatibility code in tcl/compat is still good to have.

> So I suggest to rewrite [classic] function definitions to achieve
> ANSI C conformance.

I am not sure that rewriting code just for the sake of aesthetics is
necessary.  These function definitions are tested and they work, and
there are prototypes for them in the appropriate places.

> I hope that you will also like the better type checking that can be
> provided by such a change.

In theory but not in practice.

ISO C function headers require verification that prototypes and
function headers conform to each other.  The compiler doesn't have to
check this for classic (aka "K&R") functions headers, but it *can* do
so and GCC actually does it.  Tcl is of course compiled with GCC on
Linux and other platforms all the time, so this serves as a
verification.

AFAIK in the Tcl code, all functions have prototypes at this time (or
where they haven't they certainly should have), so we can be pretty
sure that there are no hidden bugs because of this.

> Can the use of non compliant structures be stopped?  How do you
> think about the future for switches like "_ANSI_ARGS_" or
> "__STDC__"?

I think that today, it isn't really necessary or usefull to use
classic function headers, or the macros CONST, VOID and similar
compatibility stuff.  In fact, in some newer regions of the code, ISO
C prototype-style function headers are used already.

OTOH, people would like to keep the source consistent, and that is
also a reasonable POV.

I personally think it would be well worth considering to remove all
use of compatibility macros like _ANSI_ARGS_, CONST and VOID and
checks for __STDC__ from the public headers and remove or deprecate
them in the documentation.  Most of these tricks don't serve a good
purpose any more, but they confuse the description of the public
interface.  Of course, they still need to be defined, to keep old
client code compatible.

Modernisation of the actual implementation code should probably be
left at the discretion of the individual maintainers.  I'd suggest not
using the macros and classic function headers in new code, but I would
modernize old code only when major overhauls are done on a source file
anyway.


I also would be interested in hearing the opinions of others.


benny