Re: altivec: fix macros

[John Marshall <johnm at falch dot net>]

On Wed, Apr 17, 2002 at 04:15:21PM +0700, Aldy Hernandez wrote:
> Ahh if I could only meet the person who came up with altivec
> specs... Bool, unfortunately, is required by the altivec specs.
> 
>> including <stdbool.h>?
> 
> <stdbool.h> is not guaranteed to be in every system is it? (??)

I thought stdbool.h was one of the headers that was provided by GCC (or
at least *will be*, for versions of GCC that support your altivec stuff,
which would be close enough), because it's required for a freestanding C
implementation.

> Besides bool in this case is defined to unsigned, not plain int, as
> stbool.h defines it as.

I don't post much, so far be it for me to risk suggesting something that
might generate heat rather than light :-), especially over an issue that
is probably trivial, but I don't believe that GCC, in the absence of
-pedantic, is bound to follow the altivec spec precisely.  It may be
useful to do so, or it may not.  Sometimes GCC makes its own decisions
about what is useful to provide, especially when its maintainers think
some particular spec is stupid.  See in particular

	http://gcc.gnu.org/ml/gcc/2000-11/msg01090.html

If the Altivec spec requires #include <altivec.h> to provide a bool
"type", it may be more useful to a C99 user if it provided a standard
C99 one.  In particular, it seems as if it would be important for the
following two programs to do something logical and preferably to do the
same thing:

	/* foo.c */
	#include <altivec.h>
	#include <stdbool.h>
	bool foo () { return true; }

	/* bar.c */
	#include <stdbool.h>
	#include <altivec.h>
	bool bar () { return true; }

I suspect that, with your patch as it stands, at least one of these will
fail to compile without diagnostics.

    John