From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14489 invoked by alias); 26 Jul 2003 04:25:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14482 invoked from network); 26 Jul 2003 04:25:37 -0000 Received: from unknown (HELO ms-smtp-03.nyroc.rr.com) (24.92.226.153) by sources.redhat.com with SMTP; 26 Jul 2003 04:25:37 -0000 Received: from doctormoo (syr-24-24-19-190.twcny.rr.com [24.24.19.190]) by ms-smtp-03.nyroc.rr.com (8.12.5/8.12.2) with ESMTP id h6Q4Pas4014132; Sat, 26 Jul 2003 00:25:37 -0400 (EDT) Received: by doctormoo (Postfix, from userid 1000) id 9A75643CF5; Sat, 26 Jul 2003 00:25:29 -0400 (EDT) Date: Sat, 26 Jul 2003 12:42:00 -0000 To: phil@jaj.com Cc: gcc@gcc.gnu.org Subject: Re: Does C++ std::queue really conflict with C header 'struct queue'? Message-ID: <20030726042529.GA906@twcny.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i From: neroden@twcny.rr.com (Nathanael Nerode) X-SW-Source: 2003-07/txt/msg01805.txt.bz2 Phil Edwards wrote: >On Fri, Jul 25, 2003 at 10:17:16PM -0400, Nathanael Nerode wrote: >> The following hunk of code from fixinc.svr4 purports to fix a >problem, >which I >> think may not be a problem. >> >> The claim is that 'struct queue' in sys/stream.h conflicts with the >> 'queue' class in C++ headers. This seems wrong to me because the C++ >> queue class is in namespace std, and I don't see why the sys/stream.h >> version would be. > >My guess is that it dates from the days when gcc didn't have proper >namespace support. Tomorrow I'll try removing that fix and see whether >anything breaks on solaris. Thanks for picking up on this! That's what I guessed, but I wasn't comfortable with it until a C++ person said it. :-) I doubt that Solaris comes out of config.guess as "*-*-svr4*", though, so I think it doesn't use the fixinc.svr4 script, the only one which still has that fix. There is a similar issue related to math.h defining 'struct exception', which also appears in regular fixincludes. Is this essentially the same situation, or is there some added wrinkle introduced because of the forwarding headers or something? (If so, is this better fixed in 'fixincludes' or in the forwarding headers?) If this is essentially the same case, you could try removing *that* fix (hackname 'math_exception'). (I can't check that either, since my only machine uses glibc, which already has essentially incorporated the fixincludes fix into its math.h.) Mantra: Anything I can delete is a good thing. :-) -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html