>>>>> "MAL" == mal <M.-A.> writes: MAL> What are you after here ? Remove the configure.in test as well MAL> ? >> >> It is already gone. And earlier in this thread, we established >> that it did you no good, right? MAL> No and I think I was clear about the fact that I don't want MAL> this to be removed. It's clear you don't want it to be removed, but not entirely clear why. We've got a whole alpha and beta cycle to see if anyone finds an actual compiler problem with the Python core. During that time, you can see if the problem occurs for the header file you mentioned. (The one where you use it for an array even though you could rearrange the code to eliminate it.) >> You only care about compilers that choke on static array decls >> with later initialization, and the test doesn't catch that. MAL> The test tries to catch a general problem in some compilers: No one has produced any evidence that there are still compilers that have this problem. MAL> that static forward declarations cause compile time MAL> errors. However, it only tests this for structs, not arrays and MAL> functions. So not all problems related to static forward MAL> declarations are catched. That's why I had to add support for MAL> this to the header file I'm using. The Python core has no need for tests on arrays or functions. (Indeed, staticforward was not intended for function prototypes.) Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4