This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Workaround more _Bool problems on HP-UX
- From: Roger Sayle <roger at eyesopen dot com>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc-patches at gcc dot gnu dot org, <zack at codesourcery dot com>
- Date: Fri, 23 Jan 2004 11:08:44 -0700 (MST)
- Subject: Re: [PATCH] Workaround more _Bool problems on HP-UX
On Fri, 23 Jan 2004, John David Anglin wrote:
> > void foo(_Bool *ptr, _Bool val)
> > {
> > *ptr |= ! val;
> > }
>
> -bash-2.05b$ cc -Ae -S -O bool.c
> cc: "bool.c", line 1: error 1000: Unexpected symbol: "*".
> cc: "bool.c", line 1: error 1000: Unexpected symbol: ")".
> cc: "bool.c", line 3: error 1000: Unexpected symbol: ";".
> cc: "bool.c", line 3: error 1616: Unable to open intrinsic file "/usr/local/lib/
Doubly odd. My HP compiler parses the program without any problems,
and changing "|=" in the source code to just "=" allows the compiler
to generate an object file without any failures.
> So, _Bool is non functional. I image that this will get caught by the
> configure check but I haven't actually tried building 3.4 or later with
> the HP compiler.
The relevant part of my configure log is
checking for long long int... yes
checking for __int64... no
checking for built-in _Bool... yes
checking size of void *... 8
checking size of short... 2
Clearly, there are two very different HP compilers in the wild, with
different functionality and bugs. One has a builtin _Bool and not
<stdbool.h>, the other has no _Bool but provides <stdbool.h> instead.
But as Zack has commented, given we can't rely on _Bool and there
are good reasons to avoid stdbool, always using unsigned char seems
like the safest and most portable solution.
Roger
--