apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@btopenworld.com>
Subject Re: [PATCH] Fix testing of "BEOS" symbol
Date Wed, 17 Nov 2004 14:18:49 GMT
Joe Orton wrote:
> The fact that -Wundef exposed bugs like apr_signal_block() being a noop
> seems like sufficient justification to make the source -Wundef clean to
> avoid future screwups, I agree with this.  But any chance you could fix
> them all rather than picking them off one at at time?
> 
> file_io/unix/pipe.c:27:5: warning: "BEOS" is not defined
> file_io/unix/pipe.c:37:6: warning: "BEOS_BLOCKING" is not defined
> file_io/unix/pipe.c:73:6: warning: "BEOS_BLOCKING" is not defined
> file_io/unix/readwrite.c:23:6: warning: "BEOS_R5" is not defined
> support/unix/waitio.c:24:6: warning: "BEOS_R5" is not defined

The reason I didn't fix the rest, which are all BEOS-related, is that I don't 
have experience with (or test facilities for) compiling on BEOS, and it is not 
so clear how they are intended to be used (def/undef or 0/1).  I would 
certainly like them to be fixed, and started trying to do so, but I quickly 
realised that I was not easily going to achieve a solution of which I was 
confident.

The reason I made the one BEOS-related fix that I did is because it appears in 
a header file and thus the warning pops up many times, once for each C file 
that uses it, and I was able to discover the correct solution from other usage 
of the same symbol.  Where the same symbol gets a warning in pipe.c:27, it is 
in combination with other BEOS-related symbols and I was not able easily to 
find a good fix.

So, no, sorry, I'm not going to fix the other BEOS symbols.

- Julian

Mime
View raw message