On 11-12-2007 16:59:18 +0100, Stefan Manegold wrote:
original: #if HAVE_ALLOCA_H changed to: #ifdef HAVE_ALLOCA_H
Indeed, gcc on FreeBSD appears to choke on this. I fixed it in the current branch (sorry, my FreeBSD machine is too slow and I just did current initially).
If macro X is defined and equal to either 0 or 1,
#if X
is IMHO a valid C preprorocessor derective and should hence work fine. In fact, in such case the semantics of
#if X
is obviously not the same as that of
#ifdef X
(Admittedly, most in most if not all cases you changed, indeed `#ifdef X` was / should have been intended, not `#if X`.)
What excatly did the gcc on FreeBSD complain about
For my machine it was that alloca.h is not an existing include file. So the guard that should have prevented from including, did not work. This may very well not be a FreeBSD issue, as most other systems I know *DO* have alloca.h available, so it might very well just has gone unnoticed.
There are occurences of #if @1 and #if CMD_@1 in the M4, M5 and XQuery sources. I suspect they will fail in the same way (i.e. the guard may do something else than expected), but I am not sure what the appropriate fix there is.
These case *might* indeed mean what they say:
#if @1 #if CMD_@1
with @1 / CMD_@1 being either 0 or 1.
I guessed something like that. So those appear to be correct. I prefer proper comparisons in those cases anyway, but that's just beauty/readability.