[Python-Dev] staticforward

[M.-A. Lemburg]

Guido van Rossum wrote:
>>The test tries to catch a general problem in some compilers: that
>>static forward declarations cause compile time errors. However,
>>it only tests this for structs, not arrays and functions.
>>So not all problems related to static forward declarations are
>>catched. That's why I had to add support for this to the
>>header file I'm using.
>>
>>As a result, the test should be extended to also check for the
>>array case and the function case, so that all relevant static
>>forward declaration bugs in the compiler trigger the
>>#define of BAD_STATIC_FORWARD since that's what the symbol
>>is all about.
> 
> 
> Sorry, Marc-Andre, this has lasted long enough.
> 
> Compilers that don't support this are clearly broken according to the
> ANSI C std.  When Python was first released, such broken compilers
> perhaps had the excuse that it was a tricky issue in the std and that
> K&R didn't do it that way.  That was many years ago.  Platforms whose
> compiler is still broken in this way ought to be extinct, and I have
> every reason to believe that they are.

"""
Albert Chin-A-Young wrote on 2002-05-04:
 > >
 > > The AIX xlc ANSI compiler does not allow forward declaration of
 > > variables. This leads to a lot of problems with .c files that use
 > > staticforward (e.g. mxDateTime.c, mxProxy.c, etc.). Any chance of
 > > fixing these?
"""

I'm not making this up.

> It's just not worth our while to try to cater for every possible way
> that compilers used to be broken in the distant past.  When we spot a
> real live broken compiler, and there's no better work-around (like
> rewriting the code), and we care about that platform, and there's no
> alternative compiler available, we may add some cruft to the code.

This sounds too much like "we == PythonLabs". Is that
intended ?

> But there's no point in gathering cruft forever without every once in
> a while cleaning some things up.
> 
> I'll gladly put this back in as soon as you have a paying customer who
> wants to run Python 2.3 on a platform where the compiler is still
> broken in this way.  Until then, it's a non-issue.

Hmm, a few messages ago you confirmed that my usage of
staticforward and statichere was corrrect, later on, you say
that it's not necessary anymore in the core so it's OK
to rip it out. I am telling you that there are compilers
around which don't get it right for arrays and propose
to add a check for those as well -- if only to help extenions
writers like myself.

Nevermind, I'll add code to my stuff to emulate the
configure.in check using distutils. Still, I find
it frustrating that PythonLabs is giving me such a
hard time because of 15 lines of code in configure.in.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/