Re: Trouble while compiling Xemacs

On Mon, 11 Jun 2001, Valdis Kletnieks said: Aha, well this is not *necessarily* an error :) This is the Void_Null fix. That part of that header file may be compiled by G++ (it's not obviously guarded by `#ifndef __cplusplus' or similar), and in C++ ((void *)0) is an unwise definition for the null pointer constant, because that runs foul of C++'s strong typing; in both C and C++, 0 is a better definition. So we fix it to stop G++ giving lots of fatal errors on fairly elementary C programs. Now it may be that the `#ifdef _ANSI_C_SOURCE' I see at the top of that hunk is supposed to prevent this code being compiled by a C++ compiler; but, if so, they should have used #ifndef __cplusplus. `_ANSI_C_SOURCE' is just, well, silly, and fixincludes doesn't know what it means. (I can't think of any way of determining that some random preprocessor token means `C++ will not see this code' in the general case, except for some kind of hideous static analyser hooking into the C preprocessor and determining that `this must always be on if this is on' and so forth, and tracing back to __cplusplus and __STDC__ --- and even that won't spot #defines that the vendor compiler turns on and that GCC doesn't yet know that it turns on. Certainly GCC-2.95.3's essentially regex-based fixincludes wouldn't have spotted it.) I'd say that that fix is correct, within fixincludes's limited capabilities, and even a much more powerful fixincluder would probably have had to apply that transformation in that case (without a complete locale.h and all headers it includes above that point on that platform, I can't *guarantee* that it is required for proper C++ functioning, though). -- `"This code is gross!" meaning "This code has over 144 compilation errors."' --- Correct use of English, from jer