Re: Overloading vs. string functions, etc.

[Andreas Jaeger <aj at suse dot de>]

Gabriel Dos Reis <gdr@codesourcery.com> writes:

> Andreas Jaeger <aj@suse.de> writes:
> 
> | > How about `#define strcpy __glibcpp_strcpy' in std_cstring.h before
> | > including /usr/includ/string.h?  I think that would do the trick.
> | > Thoughts?
> | 
> | Gaby, isn't this the same problem we had with fabs in <math.h>?  I've
> | just asked you for guidance on gcc-patches.
> 
> The fabs() issue was even more pernicious: glibc provides another
> -definition- for fabs when optimization is on.  The end results are

Why was the definition different?  Is it the throw() clause?

> the same: programs can't get compiled :-(
> 

I see.  Since - on Linux - we can change the C Library (glibc) to work
correctly together with the C++ Library, could somebody explain in
more detail to me what is allowed for glibc and what not?

We could fix this for the next glibc release if we all agree what
needs to be done and how it should be done.

So, what can glibc do and what should glibc not do under C++
compilation (and please explain why, I'd like to learn a bit;-):
- Declare macros, e.g. for memcpy?
- Declare inline functions like fabs or strlen?
- Declare C functions and inline functions with throw()
- anything else?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj