This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


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

Re: gcc 3.0 cannot compile pooma


"Zack Weinberg" <zackw@stanford.edu> writes:

| On Wed, Jun 06, 2001 at 06:28:44AM +0200, Gabriel Dos Reis wrote:
| > Jeffrey Oldham <oldham@codesourcery.com> writes:
| > 
| > | 2) Create a separate <string.h> file.
| > | 
| > | <string.h> = <cstring>
| > | 	     using std::size_t;
| > | 	     using std::memcpy;
| > | 	     // ...
| > | 
| > | <cstring> = namespace std {
| > | 	      #include "/usr/include/string.h"	/* fully-qualified path */
| > | 	    }
| > | 
| > | <cstring> must use a fully-qualified path rather than <string.h> to
| > | avoid infinite recursion.
| > | 
| > | The latter comes closer to the standard but requires some additional
| > | work during creation to resolve the fully-qualified path.
| > 
| > On some plateforms (Robert Lipe could provide data) the actual paths
| > depends on the `-ansi -pedantic' or something like that.
| > 
| > Creating <string.h> in terms of <cstring> is what we're supposed to do
| > but...
| 
| This is exactly what #include_next is for.

Do you mean for the solving
pathnames-which-depend-on-conformance-flags problem?

| But I kind-of think that there's more to it than that.  Isn't this
| what the c_shadow headers are supposed to be doing, and they don't
| work right at the moment?

Exactly!

-- Gaby


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