[Bug libc/32024] New: sys/un.h includes header files within extern "C++" { ... }

[Bug libc/32024] New: sys/un.h includes header files within extern "C++" { ... }

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32024

            Bug ID: 32024
           Summary: sys/un.h includes header files within extern "C++" {
                    ... }
           Product: glibc
           Version: 2.40
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bruno at clisp dot org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

The <sys/un.h> header file includes other header files (<stddef.h> and
<string.h>) from within an extern "C++" { ... } block (written as __BEGIN_DECLS
and __END_DECLS).

While this has no ill effects with the glibc definitions of <stddef.h> and
<string.h>, it causes compilation errors when used with GNU Gnulib. Gnulib
augments <stddef.h> and <string.h> with additional declarations, by use of
#include_next. When these overridden header files are included from within an
extern "C++" { ... } block, with clang++, this leads to errors ("error:
declaration of 'memchr' has a different language linkage" etc.). See
<https://lists.gnu.org/archive/html/bug-gnulib/2024-07/msg00261.html>.

Find attached a fix, that moves the includes outside the extern "C++" { ... }
block.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/32024] sys/un.h includes header files within extern "C++" { ... }

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32024

--- Comment #1 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 15642
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15642&action=edit
proposed fix

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/32024] sys/un.h includes header files within extern "C++" { ... }

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32024

Eric Blake <eblake at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblake at redhat dot com

--- Comment #2 from Eric Blake <eblake at redhat dot com> ---
Unrelated to the patch, but while we're in the area:

# define SUN_LEN(ptr) (offsetof (struct sockaddr_un, sun_path)                \
   strlen ((ptr)->sun_path))

But at least Linux allows the use of ALL bytes in the length-limited sun_path[]
to be non-NULL (while not portable to all implementations, it does let
GNU/Linux systems use one extra byte for the name of a Unix socket). 
Therefore, shouldn't this macro be using strnlen() instead of strlen()?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/32024] sys/un.h includes header files within extern "C++" { ... }

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32024

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
__BEGIN_DECLS is defined to extern "C", not extern "C++", so I don't see how
that can result in misbehaviour.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/32024] sys/un.h includes header files within extern "C++" { ... }

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32024

--- Comment #4 from Bruno Haible <bruno at clisp dot org> ---
(In reply to Andreas Schwab from comment #3)
> __BEGIN_DECLS is defined to extern "C", not extern "C++"

Indeed, I should have written extern "C" instead of extern "C++" in the bug
description.

> so I don't see how that can result in misbehaviour.

Here's a minified test case:
1. Store the attached test.cc and string.h in the same directory.
2. Compile test.cc with clang (I use clang 18):

$ clang++ -I. -c test.cc
In file included from test.cc:5:
In file included from /usr/include/x86_64-linux-gnu/sys/un.h:37:
./string.h:6:15: error: declaration of 'memchr' has a different language
linkage
    6 | extern void * memchr (void *__s, int __c, size_t __n) noexcept (true)
      |               ^
/usr/include/string.h:87:14: note: previous declaration is here
   87 | extern void *memchr (void *__s, int __c, size_t __n)
      |              ^
In file included from test.cc:5:
In file included from /usr/include/x86_64-linux-gnu/sys/un.h:37:
./string.h:8:21: error: declaration of 'memchr' has a different language
linkage
    8 | extern void const * memchr (void const *__s, int __c, size_t __n)
noexcept (true)
      |                     ^
/usr/include/string.h:89:20: note: previous declaration is here
   89 | extern const void *memchr (const void *__s, int __c, size_t __n)
      |                    ^
2 errors generated.

3. Compile test.cc with clang, this time defining WORKAROUND to 1:

$ clang++ -I. -c test.cc -DWORKAROUND
(no errors)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/32024] sys/un.h includes header files within extern "C++" { ... }

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32024

--- Comment #5 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 15702
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15702&action=edit
test case 1st file: test.cc

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/32024] sys/un.h includes header files within extern "C++" { ... }

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32024

--- Comment #6 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 15703
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15703&action=edit
test case 2nd file: string.h

-- 
You are receiving this mail because:
You are on the CC list for the bug.