[Python-Dev] staticforward

[Guido van Rossum]

> 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.

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.
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.

--Guido van Rossum (home page: http://www.python.org/~guido/)