Date: Sun, 23 Oct 2022 10:56:40 -0700
On Sunday, 23 October 2022 01:26:09 PDT Lénárd Szolnoki via Std-Proposals
wrote:
> Hi,
>
> How is the slight strchr divergence between the C and C++ standard libraries
> handled?
Very carefully.
It didn't use to be handled at all and there used to be problems with improper
compliance. I wouldn't be surprised if it still happens.
Right now, you have *both* the C++ library and the C libraries working around
this. libstdc++ cstring defines its own std::strchr and memchr as inline
functions, that call a compiler intrinsic. libc++'s don't and they instead
require that the C library's string.h have the proper C++ definitions.
glibc's string.h does define C++ overloads for strchr, strrchr and memchr by
using symbol renaming. Bionic's string.h does not... so is this even working
on today's Android NDK?
wrote:
> Hi,
>
> How is the slight strchr divergence between the C and C++ standard libraries
> handled?
Very carefully.
It didn't use to be handled at all and there used to be problems with improper
compliance. I wouldn't be surprised if it still happens.
Right now, you have *both* the C++ library and the C libraries working around
this. libstdc++ cstring defines its own std::strchr and memchr as inline
functions, that call a compiler intrinsic. libc++'s don't and they instead
require that the C library's string.h have the proper C++ definitions.
glibc's string.h does define C++ overloads for strchr, strrchr and memchr by
using symbol renaming. Bionic's string.h does not... so is this even working
on today's Android NDK?
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2022-10-23 17:56:42