string.h and std_cstring.h

string.h and std_cstring.h

[Graeme Peterson]

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

Re: string.h and std_cstring.h

[Joe Buck]

> 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.

Re: string.h and std_cstring.h

[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.
> 
> 



-- 

Re: string.h and std_cstring.h

[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

Re: string.h and std_cstring.h

[Graeme Peterson]

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.
> > 
> > 
> 
> 
> 
> -- 
> 
> 
> 
>