Thread

  1. Re: C11: should we use char32_t for unicode code points?

    Jeff Davis <pgsql@j-davis.com> — 2025-10-28T21:54:35Z

    On Wed, 2025-10-29 at 09:03 +1300, Thomas Munro wrote:
    > If you try to test for the existence of the type rather than the
    > header in meson/configure, won't you still have the configure-with-C
    > compile-with-C++ problem
    
    I must have misunderstood the first time. If we depend on
    HAVE_CHAR32_T, then it will be set in stone in pg_config.h, and if C++
    tries to include the file then it will try the typedef again and fail.
    
    I tried with headerscheck --cplusplus before posting it, but because my
    machine has uchar.h, then it didn't fail.
    
    I went back to using the check for __cplusplus, and added a comment
    that hopefully clarifies things.
    
    I also reordered the checks so that it prefers to include uchar.h if
    available, even when using C++, because that seems like the cleaner end
    goal. However, that caused another problem in CI (mingw_cross_warning),
    apparently due to a conflict between uchar.h and win32_port.h on that
    platform:
    
    [21:48:21.794] ../../src/include/port/win32_port.h: At top level:
    [21:48:21.794] ../../src/include/port/win32_port.h:254:8: error:
    redefinition of ‘struct stat’
    [21:48:21.794]   254 | struct stat                                    
    /* This should match struct __stat64 */
    [21:48:21.794]       |        ^~~~
    [21:48:21.794] In file included from /usr/share/mingw-
    w64/include/wchar.h:413,
    [21:48:21.794]                  from /usr/share/mingw-
    w64/include/uchar.h:28,
    [21:48:21.794]                  from ../../src/include/c.h:526:
    [21:48:21.794] /usr/share/mingw-w64/include/_mingw_stat64.h:40:10:
    note: originally defined here
    [21:48:21.794]    40 |   struct stat {
    [21:48:21.794]       |          ^~~~
    
    https://cirrus-ci.com/task/4849300577976320
    
    I could reverse the checks again and I think it will work, but let me
    know if you have an idea for a better fix.
    
    I never thought it would be so much trouble just to get a suitable type
    for a UTF-32 code point...
    
    Regards,
    	Jeff Davis