Re: cpluspluscheck vs ICU

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: cpluspluscheck vs ICU
Date: 2023-03-11 04:10:30
Message-ID: 20230311041030.bh7db7wdtiivblrz@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-03-10 19:37:27 -0800, Andres Freund wrote:
> On 2022-03-23 08:56:17 -0700, Andres Freund wrote:
> > On 2022-03-23 08:19:38 -0400, Andrew Dunstan wrote:
> > > On 3/22/22 22:23, Andres Freund wrote:
> > > That only helps when running the CI/cfbot setup. Fixing it for other
> > > (manual or buildfarm) users would be nice. Luckily crake isn't building
> > > with ICU.
> >
> > Oh, I agree we need to fix it properly. I just don't yet know how to - see the
> > list of alternatives upthread. Seems no reason to hold up preventing further
> > problems via CI / cfbot though.
>
> I just hit this once more - and I figured out a fairly easy fix:
>
> We just need a
> #ifndef U_DEFAULT_SHOW_DRAFT
> #define U_DEFAULT_SHOW_DRAFT 0
> #endif
> before including unicode/ucol.h.
>
> At first I was looking at
> #define U_SHOW_CPLUSPLUS_API 0
> and
> #define U_HIDE_INTERNAL_API 1
> which both work, but they are documented to be internal.

Err. Unfortunately only the U_SHOW_CPLUSPLUS_API approach actually works. The
others don't, not quite sure what I was doing earlier.

So it's either relying on a define marked as internal, or the below:

> Alternatively we could emit U_DEFAULT_SHOW_DRAFT 0 into pg_config.h to avoid
> that issue.
>
>
> The only other thing I see is to do something like:
>
> #ifdef USE_ICU
> #ifdef __cplusplus
> /* close extern "C", otherwise we'll get errors from within ICU */
> }
> #endif /* __cplusplus */
>
> #include <unicode/ucol.h>
>
> #ifdef __cplusplus
> extern "C" {
> #endif /* __cplusplus */
>
> #endif /* USE_ICU */
>
> which seems mighty ugly.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-03-11 04:14:47 Re: proposal - get_extension_version function
Previous Message Thomas Munro 2023-03-11 03:59:46 Re: Dead code in ps_status.c