From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17994 invoked by alias); 8 Jul 2006 01:57:46 -0000 Received: (qmail 17968 invoked by uid 22791); 8 Jul 2006 01:57:45 -0000 X-Spam-Check-By: sourceware.org Received: from smtp103.sbc.mail.mud.yahoo.com (HELO smtp103.sbc.mail.mud.yahoo.com) (68.142.198.202) by sourceware.org (qpsmtpd/0.31) with SMTP; Sat, 08 Jul 2006 01:57:43 +0000 Received: (qmail 6132 invoked from network); 8 Jul 2006 01:57:40 -0000 Received: from unknown (HELO ?68.125.129.157?) (timothyprince@sbcglobal.net@68.125.129.157 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 8 Jul 2006 01:57:40 -0000 Message-ID: <44AF1111.9020000@sbcglobal.net> Date: Sat, 08 Jul 2006 01:57:00 -0000 From: Tim Prince Reply-To: tprince@myrealbox.com User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Ian Lance Taylor CC: Timothy C Prince , gdr@integrable-solutions.net, gcc-help@gcc.gnu.org Subject: Re: deprecated conversion from string constant to 'char *' References: <1152307019.c7e15c3ctprince@myrealbox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-07/txt/msg00082.txt.bz2 Ian Lance Taylor wrote: > "Timothy C Prince" writes: > >> gcc built from last Saturday's post on gcc.gnu.org/pub/gcc/snapshots >> >> I've seen remarks about that not being a reliable source for FSF gcc. If those aren't good to use, why not offer something better? > > That is a reliable source for FSF gcc snapshots. > > Of course snapshots are just that: a snapshot of the development in > progress. They are not guaranteed to work. > > We still can't help with you without a complete and exact description > of precisely what you are doing. > > Ian > > Ian, The example you made up is good enough. As you can see from the follow-ups, replacing 'char *' by 'const char *' in your example, or (consistently throughout) in my own case, solve the problem. The question remains whether g++ should abort the compilation when the legacy source code is discovered. If it does abort, with no option to continue (as it does in my testing), should it be reported as Error rather than warning? Should g++ -m32 produce a diagnostic similar to g++ -m64? In case it's of interest, I've investigated the following compilers: g++ 4.2 x86-64 reports "deprecated conversion" (and aborts) when const is omitted g++ 4.2 -m32 x86-64, and Windows 32-bit, fail on a bunch of libstdc++ problems relative to char * conversions, when const is omitted Intel icpc 9.1 linux x86-64 doesn't care whether const is present, no warning available (consistent with g++ 4.0.2 as base installation) Intel ICL 9.1 Windows x64 has STL problems when const is omitted (unable to verify whether that corresponds to behavior of base MSVC++ installation) MSVC 2003 toolkit 32-bit fails on excessive warnings without const, if -Wall is set, otherwise accepts either version So, I'm satisfied that 'const char *' is the correct solution, and that no consistent treatment of legacy code (warning/abort/no warning/STL failure) can be expected of current compilers. Thanks, Tim