From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=sI90=BB=groessler.org=chris@sourceware.org>
Received: from vigilia.groessler.org (vigilia.groessler.org [79.143.177.135])
	by sourceware.org (Postfix) with ESMTPS id 4CE4E3858C54
	for <gcc@gcc.gnu.org>; Fri, 12 May 2023 08:45:50 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CE4E3858C54
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=groessler.org
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=groessler.org
Received: from [10.23.1.23] (gaga.groessler.org [212.168.189.235])
	by vigilia.groessler.org (8.16.0.45/8.14.6) with ESMTPS id 34C8jmYg097272
	(version=TLSv1.3 cipher=AEAD-AES128-GCM-SHA256 bits=128 verify=NO)
	for <gcc@gcc.gnu.org>; Fri, 12 May 2023 10:45:48 +0200 (CEST)
Message-ID: <c80e7171-52f7-1c5e-af0d-5e8db6531659@groessler.org>
Date: Fri, 12 May 2023 10:45:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: More C type errors by default for GCC 14
To: gcc@gcc.gnu.org
References: <877cth66qb.fsf@oldenburg.str.redhat.com>
 <CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
 <CAH6eHdS5=AED+7MSe0prr8CZ-sYqnD159OjhTp9=R-a0aBZ3qw@mail.gmail.com>
 <20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net>
 <87r0rp5uf8.fsf@aarsen.me> <83ttwla1ep.fsf@gnu.org>
 <CAH6eHdS-7USHzX3rPJaR66sEdjG+-nHp7mDb0gD7ceBnp+Fmpg@mail.gmail.com>
 <83lehx9vix.fsf@gnu.org> <ZFqZ25xKm4w4IkqF@tucnak> <83fs859unu.fsf@gnu.org>
 <87y1lx1avj.fsf@oldenburg.str.redhat.com> <83ednoapb6.fsf@gnu.org>
 <CAH6eHdS0KEyfLdE9fvTJ3aLtudKXcL9PyqPASJJVEgTMD6FaUQ@mail.gmail.com>
 <875y8zegnc.fsf@yahoo.com> <865y8zmi08.fsf@aarsen.me>
 <87bkirclqv.fsf@yahoo.com> <86a5ybjlbd.fsf@aarsen.me>
 <83ilcz5f5e.fsf@gnu.org> <865y8y8tjr.fsf@aarsen.me> <834joi3s07.fsf@gnu.org>
Content-Language: en-US
From: Christian Groessler <chris@groessler.org>
In-Reply-To: <834joi3s07.fsf@gnu.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc.gcc.gnu.org>

On 5/12/23 09:53, Eli Zaretskii via Gcc wrote:
> 
>> With all that to consider, is it *really* a significant cost to add
>> -fpermissive?
> 
> See above (and my earlier message): the significant cost is to
> discover the root cause of the problem, and that -fpermissive is the
> solution.  The rest might be relatively easier, at least in some
> projects.


-fpermissive seems to be posted as the standard solution in this thread,

I don't know what constructs it allows, but it might enable things the 
user doesn't want besides silencing this new change.

So it seems to be more effort than to "just add -fpermissive" to get the 
code to compile again.

Think about big code bases where many developers are working on in 
different areas.

regards,
chris