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 03:37:27
Message-ID: 20230311033727.koa4saxy5wyquu6s@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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.

The reason for the #ifndef is that pg_locale.h might be included by .c files
that already included ICU headers, which then otherwise would cause macro
redefinition warnings. E.g. in formatting.c.

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.

Regards,

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-03-11 03:59:46 Re: Dead code in ps_status.c
Previous Message Julien Rouhaud 2023-03-11 03:32:32 Re: pg_dump versus hash partitioning