This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unreviewed patches


Roger Sayle <roger@eyesopen.com> writes:

| > > But getting back to that particular patch at hand, both ::strlen and
| > > std::strlen will need to be anticipated in this new scheme.  And both
| >
| > No, they need to be inline functions in the C++ headers that call
| > __builtin_strlen.  For C++ we control the standard headers (and only the
| > headers, not explicit declarations by users, can be used to access the
| > functions) so can readily do this.  Given them inline in the headers,
| > we don't then need the compiler to make them built-in.
| 
| No.  I'd like to agree with you, but your vision of a world where g++
| controlled the system headers and defined all the standard C library
| functions as C++ inline functions calling __builtin_ versions is almost
| science fiction.

It is only science fiction if you think the library is correctly
implemented; and it is not.  That is a known issue.  Any work on the
compiler front-end in that regard should be coordinated with the
library folks, and note done in isolation, i.e. not complicated the
issue further.


|  Including <string.h> on most g++ platforms includes the
| system /usr/include/string.h, (i.e. the one shared with the native system
| compiler) which often doesn't contain a complete set of GCC function
| attribute extensions, and in order to work with C compilers, often isn't
| a C++ inline function wrapper.

That is a known issue.  It is also known that on a systems where we
can control the system C-header (e.g. Glibc-systems), the Glibc folks
will cooperate with us and mke the appropriatte declarations in the
appropriate headers.  Patching, in isolation, the front-end to do
something not fully understood, not in accordance with the library
folks expectations, isn't something I call a fix.


| To point out some of the flaws in both your and Gaby's arguments,
| consider the following simple source file:
| 
| #include <string.h>
| 
| int foo () { return ::strlen("Hello world"); }
| int bar () { return std::strlen("Hello world"); }
| 
| When compiled using g++ v3.1 on both i686-pc-cygwin and i686-pc-linux-gnu
| (redhat 7.2),  bar gives a warning message that strlen is undeclared in
| namespace std (sorry Gaby), and the resulting foo contains an explicit
| call to "strlen".

That is a flaw neither in my arguments, nor in Joseph's.  What I
described is the standard requirement.  That, in its actual form, it
is not implemented is a serious issue we've considered in the past and
still considering.  That is what makes me nervous about your insisting
getting your patch in the tree, while it doesn't meet our expectations.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]