This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug string/19618] New: regression in signatures provided for <string.h> functions in C++ with non-GCC compilers


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

            Bug ID: 19618
           Summary: regression in signatures provided for <string.h>
                    functions in C++ with non-GCC compilers
           Product: glibc
           Version: 2.22
            Status: NEW
          Severity: normal
          Priority: P2
         Component: string
          Assignee: unassigned at sourceware dot org
          Reporter: richard at metafoo dot co.uk
  Target Milestone: ---

Commit 8e2e833ac4d6509b152d6b8d74d388725717c56f regressed glibc's support for
C++ in non-GCC compilers.

C++ requires that 5 functions from <string.h> and 5 functions from <wchar.h>
are overloaded, with overloads that take and return 'const char*' and overloads
that take and return 'char*' (the corresponding C functions take 'const char*'
and return 'char*' pointing to the same object, violating const correctness).
These overloads must be provided by the C standard library implementation, as
it is not possible for a C++ standard library implementation to fix the
signatures provided by the C standard library (unless it relies on a compiler
extension or doesn't include the C library's <string.h> -- thus losing all of
the C library's extensions).

glibc should be providing these overloads whenever it is compiling C++ code,
and that is what it used to do, but the referenced commit (for bug 17631)
removed that support for all compilers other than GCC. In particular, when
compiling with clang, the overloads are no longer available.

The rationale for the removal was that the current implementation relies on
__asm, which is non-portable, but the feature can be implemented without
reliance on __asm with a pattern like this:

__extern_always_inline void *
__call_memchr(const void *__s, int __c, size_t __n) __THROW
{
  extern void *memchr(const void *, int, size_t);
  return memchr(__s, __c, __n);
}

extern "C++" inline void *
memchr(void *__s, int __c, size_t __n) __THROW
{
  __call_memchr(__s, __c, __n);
}

extern "C++" inline const void *
memchr(const void *__s, int __c, size_t __n) __THROW
{
  __call_memchr(__s, __c, __n);
}

(The __call_memchr function is required in order to make the real, 'extern
"C"', memchr function callable from the extern "C++" memchr overloads.)

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]