* string.h and std_cstring.h
@ 2002-08-02 14:11 Graeme Peterson
2002-08-02 15:10 ` Joe Buck
2002-08-05 6:23 ` J.T. Conklin
0 siblings, 2 replies; 5+ messages in thread
From: Graeme Peterson @ 2002-08-02 14:11 UTC (permalink / raw)
To: gcc
Hi, all.
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.
It seems to me that std_cstring.h is assuming that these
functions will always be macros, and that this is not always
true.
If I wrap the definitions in std_cstring.h with an ifdef, and
then undef them and declare them inline, things work.
ie: (similarly for the other 4)
#ifdef memchr
#undef memchr // moved from the top of the file
using ::memchr;
inline void*
memchr(void* __p, int __c, size_t __n)
{ return memchr(const_cast<const void*>(__p), __c, __n); }
#endif
I also tried renaming the inline functions in our string.h to be
"__ntomemchr", etc..., and then defining macros:
#define memchr __ntomemchr
etc...
This met with limited success, as our memchr declaration returns
"const void*", where gcc's is "void *", and the build failed with:
error: invalid conversion from `const void*' to `void*'
Comments? Am I missing something?
Thanks.
Regards,
GP
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: string.h and std_cstring.h
2002-08-02 14:11 string.h and std_cstring.h Graeme Peterson
@ 2002-08-02 15:10 ` Joe Buck
2002-08-02 20:12 ` gp
2002-08-05 6:23 ` J.T. Conklin
1 sibling, 1 reply; 5+ messages in thread
From: Joe Buck @ 2002-08-02 15:10 UTC (permalink / raw)
To: Graeme Peterson; +Cc: gcc
> 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.
> ...
> Comments? Am I missing something?
It sounds like you may be running into trouble because C++ requires
overloading for certain functions. For example, in C, strchr is
char* strrchr(const char *, int);
while in C++ there are two:
const char* strrchr(const char *, int);
char* strrchr(char *, int);
So, if your OS provides only a C version of strchr, you still have
work to do to get the C++ versions right.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: string.h and std_cstring.h
2002-08-02 15:10 ` Joe Buck
@ 2002-08-02 20:12 ` gp
2002-08-06 11:26 ` Graeme Peterson
0 siblings, 1 reply; 5+ messages in thread
From: gp @ 2002-08-02 20:12 UTC (permalink / raw)
To: Joe Buck, Graeme Peterson; +Cc: gcc
Thanks, Joe. That could be it. Our header has something like:
#ifdef _cplusplus
#define Const_ret const
#else
#define Const_ret
#endif
..
..
extern Const_ret char* strrchr(Const_ret char *, int);
..
..
So if I am remembering it right (I'm at home right now), then we get one or
the other, but never both. I am not sure about the inlines, but I will check.
I will work on it and let you all know.
Thanks again.
GP
Joe Buck <Joe.Buck@synopsys.com> said:
>
> > 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.
> > ...
>
> > Comments? Am I missing something?
>
> It sounds like you may be running into trouble because C++ requires
> overloading for certain functions. For example, in C, strchr is
>
> char* strrchr(const char *, int);
>
> while in C++ there are two:
>
> const char* strrchr(const char *, int);
> char* strrchr(char *, int);
>
> So, if your OS provides only a C version of strchr, you still have
> work to do to get the C++ versions right.
>
>
--
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: string.h and std_cstring.h
2002-08-02 14:11 string.h and std_cstring.h Graeme Peterson
2002-08-02 15:10 ` Joe Buck
@ 2002-08-05 6:23 ` J.T. Conklin
1 sibling, 0 replies; 5+ messages in thread
From: J.T. Conklin @ 2002-08-05 6:23 UTC (permalink / raw)
To: Graeme Peterson; +Cc: gcc
"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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: string.h and std_cstring.h
2002-08-02 20:12 ` gp
@ 2002-08-06 11:26 ` Graeme Peterson
0 siblings, 0 replies; 5+ messages in thread
From: Graeme Peterson @ 2002-08-06 11:26 UTC (permalink / raw)
To: gp; +Cc: Joe Buck, gcc
I had a look at our header, and it seems good to me.
What we have is: (using only memchr for the example)
#ifdef __cplusplus
#define _Const_return const
#else
#define _Const_return
#endif
__BEGIN_DECLS
_C_STD_BEGIN
extern _Const_return void *memchr( const void *__s, int __c, size_t __n );
_C_STD_END
__END_DECLS
#ifdef __cplusplus
_C_STD_BEGIN
inline void *memchr(void *_S, int _C, _CSTD size_t _N)
{ /* call with const first argument */
union { void *_Out; _Const_return void * _In; } _Result;
return (_Result._In = _CSTD memchr((const void *)_S, _C, _N)), _Result._Out; }
_C_STD_END
#endif
#ifdef _STD_USING
#ifndef __GCC_BUILTIN
using std::memchr;
#endif
So we get both the const and the non-const C++ prototypes, and so all is
good.
The issue as I see it after my investigation, is that gcc's headers
assume that these things are going to be macros. Do either the C or C++
specs specify that these things must be macros? They say that if they are
undefined they have to still work, which they do in our case also. I mean
that question sincerely. I couldn't find anywhere that says they have to
be macros, but that just means I didn't find it.
I grepped for the assumtive comment in libstdc++-v3/include/c_std:
$ grep "Get rid of those macros defined in" *
std_cctype.h:// Get rid of those macros defined in <ctype.h> in lieu of real functions.
std_clocale.h:// Get rid of those macros defined in <locale.h> in lieu of real functions.
std_cmath.h:// Get rid of those macros defined in <math.h> in lieu of real functions.
std_csetjmp.h:// Get rid of those macros defined in <setjmp.h> in lieu of real functions.
std_csignal.h:// Get rid of those macros defined in <signal.h> in lieu of real functions.
std_cstdio.h:// Get rid of those macros defined in <stdio.h> in lieu of real functions.
std_cstdlib.h:// Get rid of those macros defined in <stdlib.h> in lieu of real functions.
std_cstring.h:// Get rid of those macros defined in <string.h> in lieu of real functions.
std_ctime.h:// Get rid of those macros defined in <time.h> in lieu of real functions.
std_cwchar.h:// Get rid of those macros defined in <wchar.h> in lieu of real functions.
std_cwctype.h:// Get rid of those macros defined in <wctype.h> in lieu of real functions.
It seems to me that a proper fix would be to change the above headers
to do something like: (memchr and std_cstring.h for the example)
From:
#undef memchr
namespace std
{
using ::memchr;
inline void*
memchr(void* __p, int __c, size_t __n)
{ return memchr(const_cast<const void*>(__p), __c, __n); }
}
To:
namespace std
{
#ifdef memchr // Only undef and override if these are macros.
#undef memchr
using ::memchr;
inline void*
memchr(void* __p, int __c, size_t __n)
{ return memchr(const_cast<const void*>(__p), __c, __n); }
#endif
}
That way the macros are only overridden if they are macros, as the
#ifdef fails for the real functions.
Again, comments and feedback appreciated.
Regards,
GP
>
> Thanks, Joe. That could be it. Our header has something like:
>
> #ifdef _cplusplus
> #define Const_ret const
> #else
> #define Const_ret
> #endif
> ..
> ..
> extern Const_ret char* strrchr(Const_ret char *, int);
> ..
> ..
>
> So if I am remembering it right (I'm at home right now), then we get one or
> the other, but never both. I am not sure about the inlines, but I will check.
>
> I will work on it and let you all know.
>
> Thanks again.
> GP
>
> Joe Buck <Joe.Buck@synopsys.com> said:
>
> >
> > > 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.
> > > ...
> >
> > > Comments? Am I missing something?
> >
> > It sounds like you may be running into trouble because C++ requires
> > overloading for certain functions. For example, in C, strchr is
> >
> > char* strrchr(const char *, int);
> >
> > while in C++ there are two:
> >
> > const char* strrchr(const char *, int);
> > char* strrchr(char *, int);
> >
> > So, if your OS provides only a C version of strchr, you still have
> > work to do to get the C++ versions right.
> >
> >
>
>
>
> --
>
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-08-06 11:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-02 14:11 string.h and std_cstring.h Graeme Peterson
2002-08-02 15:10 ` Joe Buck
2002-08-02 20:12 ` gp
2002-08-06 11:26 ` Graeme Peterson
2002-08-05 6:23 ` J.T. Conklin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).