Re: Build failure with GCC 15 (defaults to -std=gnu23)

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++.

In response to

Responses

Browse pgsql-bugs by date

  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)