Tom Lane wrote:
> William Gray <[EMAIL PROTECTED]> writes:
>   
>> I'm not sure how I'd go about determining that.  I don't recall messing
>> with any of my system's .h files.  Do you know where I might look?
>>     
>
> grep through all the files under /usr/include looking for "bool" ...
>
>                       regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>   


Looks like there are quite a few possible culprits, as it seems to be an
often-defined thing (but I must not shrink from the task...)


c.h defines a bool, and this looks correct and un-tampered with (grep
output)

> c.h: *  file.  Added bool enum from machine/types.h for regular users
> c.h: *  that want a real boolean type.
> c.h:#ifndef     bool
> c.h:typedef enum        { false = 0, true = 1 } bool;
> c.h:#endif      /* bool */

Both curses.h and ncurses.h appear to use whatever the compiler
considers bool, and if absent, defines their own.

There's a file stdbool.h that may be at fault:

> stdbool.h: * $FreeBSD: src/include/stdbool.h,v 1.6 2002/08/16 07:33:14
> alfred Exp $
> stdbool.h:#define       __bool_true_false_are_defined   1
> stdbool.h:#define       bool    _Bool

That is explicitly redefining 'bool' to be of type _Bool. 

I feel a little lost here.  I'm pretty sure I've never messed with these
files.  Is it possible that at some point if I configured some piece of
software with a prefix of /usr that it could have added some header file
to /usr/include that would adversely affect other builds, like postgres?

Thanks for your help,
Bill
begin:vcard
fn:William  Gray
n:Gray;William 
org:Montclair State University;Systems and Security Group
email;internet:[EMAIL PROTECTED]
title:Systems Developer
tel;cell:[EMAIL PROTECTED]
note:SMS: [EMAIL PROTECTED]
x-mozilla-html:TRUE
url:http://tokyo.montclair.edu/blogs/grayw/
version:2.1
end:vcard

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to