Re: string.h and std_cstring.h

[jtc at acorntoolworks dot com (J.T. Conklin)]

"Graeme Peterson" <gp@qnx.com> writes:
> I am working on the QNX i386-nto support in gcc again.
> 
> The current stumbling block is that our string.h declares
> memchr, strchr, strpbrk, strrchr, and strstr as inline.
> 
> So does libstdc++-v3/include/c_std/std_cstring.h.  This
> cause libstdc++ to not build.  

> Comments?  Am I missing something?

The QNX libstdc++ port requires it be configured with --enable-
cheaders=c.  There are a couple of problems with this approach 
that I haven't yet been able to resolve, but it is good enough
for us to use our GCC port to generate code for our product.

The first problem is that including <cstdio>, etc. will cause the
functions to be exported intro the standard namespace because the
"c" headers don't have the magic necessary to avoid exporting them
(on QNX undefining _STD_USING, including the header, and then 
redefining _STD_USING).  I've been told that Solaris uses a similar
mechanism, so I've been hoping to get some free time so I can come
up with a solution that will work for both.

The second problem is minor in comparison.  The "c_std" headers
contain macros that use gcc' __builtin_foo() intrinsics.  Since this
is just performance rather than correctness, it's probably best that
these be added to the base OS headers.  I don't think that using
fixincludes is appropriate for this purpose.

If you check in the libstdc++ mailing list archives, you'll see all
the discussion wrt. the QNX port when I was contributing it.

        --jtc

-- 
J.T. Conklin