From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sam James <sam(at)gentoo(dot)org>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Build failure with GCC 15 (defaults to -std=gnu23) |
Date: | 2024-11-17 22:45:24 |
Message-ID: | CA+hUKGJEnmapE7YYEfdJYZ-yGmcDpVGRrQ_eEVdcux26ZNJq_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Nov 18, 2024 at 10:49 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yeah. Well, what say we leave the "typedef unsigned char bool"
> pathway in place, but set things up to use that only if sizeof
> the stdbool type isn't 1 --- and then it's up to any hypothetical
> users of that pathway to choose a compiler and compiler options
> that won't choke on it.
It sounds like we should stop using the old and broken
AC_CHECK_HEADER_STDBOOL macro. I think it was doing two jobs in old
times: there were some systems that shipped a defective/pre-standard
stdbool.h, and some systems without it. I think both classes of
system are gone from the universe. Later autoconf versions check for
C99 "or later", but we're stuck with the old one and I doubt we are
going to upgrade it. Found in their NEWS:
*** AC_HEADER_STDBOOL, AC_CHECK_HEADER_STDBOOL are obsolescent and less picky.
These macros are now obsolescent, as programs can simply include
stdbool.h unconditionally. If you use these macros, they now accept
a stdbool.h that exists but does nothing, so long as ‘bool’, ‘true’,
and ‘false’ work anyway. This is for compatibility with C 2023 and
with C++.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-11-17 22:50:47 | Re: Build failure with GCC 15 (defaults to -std=gnu23) |
Previous Message | Tom Lane | 2024-11-17 21:49:29 | Re: Build failure with GCC 15 (defaults to -std=gnu23) |