From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 782123858D35 for ; Sun, 14 May 2023 10:29:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 782123858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1py8yb-000392-Hb for gcc@gcc.gnu.org; Sun, 14 May 2023 12:29:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc@gcc.gnu.org From: David Brown Subject: Re: More C type errors by default for GCC 14 Date: Sun, 14 May 2023 12:29:10 +0200 Message-ID: References: <87mt2behdl.fsf@yahoo.com> <57238276-5966-98d6-d5f0-f5451013ed17@gmail.com> <871qjned25.fsf@yahoo.com> <67e65b41-5400-d1c2-9f43-f94d0ea7da9b@gmail.com> <87wn1fcrw4.fsf@yahoo.com> <4d2af697-2f28-9e17-6b35-3a4ba19313d2@gmail.com> <87mt2ab8te.fsf@yahoo.com> <83bkiq3umf.fsf@gnu.org> <87sfc18z66.fsf@yahoo.com> <1cb56b16-1ee0-e233-30f2-464c30d19fd4@gmail.com> <87y1lt6ouy.fsf@yahoo.com> <4ea0b0de-c1f6-0708-eb57-69b4b0e458fc@gmail.com> <87353z7a7o.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Content-Language: en-GB In-Reply-To: <87353z7a7o.fsf@yahoo.com> X-Spam-Status: No, score=-3030.9 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_NUMSUBJECT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 14/05/2023 07:28, Po Lu via Gcc wrote: > Eli Schwartz writes: > >> Quoting my previous reply on the topic. >> >> Until everyone is on the same page as you about whether these are GNUC >> extensions, this conversation will go nowhere. >> >> You are of the opinion that "GCC currently behaves a certain way when >> compiling the code" means that the behavior is documented and specified >> as a "C Extension" for the GNUC language dialect. > > Yes, by the definition of ``extension'' used by everyone except you. I can't speak for "everyone", and I don't think you can either. But I believe I am safe in saying that everyone who has expressed an opinion in this thread, agrees with Eli's definition - GCC C extensions are what the GCC C manual documents as extensions. The behaviour of a particular compiler does not define the extensions. At best, these are "undocumented features" - if you find them consistent enough and useful enough on a particular version of a particular compiler, then you may be willing to rely on them despite a lack of any kind of guarantees or documentation. (You might note that there are several compilers, not just GCC, that implement many of the GNU C extensions. I don't believe any of them makes any guarantees about your imagined undocumented extensions either.) > >> Undefined and undocumented behavior is not a language extension. It is >> undefined and undocumented behavior. > > But when it becomes defined by the translator, in a precise way, it > becomes an extension to the Standard. No, it becomes an artefact of the particular implementation. And if you have studied that implementation closely enough to see that it fulfils the specifications you want, not just its actual specifications, then feel free to keep that implementation and use it. But you have absolutely no basis for expecting that any other implementation (such as future gcc versions) implement the same undocumented specifications. > >> You may feel free to take an exact GCC release (source or binary), >> analyze it, reverse-engineer it, or verify that it does what you want >> it to do, and then trust that those undefined and undocumented >> behaviors are ***benevolent***, but that doesn't cause it to be >> defined and documented, and your trust will, if you are wise, depend >> on you pinning an exact source code commit of the compiler. Do not >> depend on bugfix releases of GCC to preserve your undocumented >> semantics. They may or they may not, but if they don't, it's not a GCC >> bug, because it is ***undocumented***. > > GCC does not implement its documentation. The documentation is supposed > to describe (_not_ specify) how GCC behaves, and when the documentation > is wrong or contains omissions, the documentation will have to be fixed. > Not the compiler itself. > > And it's not just GCC. Almost all programs work this way. > It is a sad fact that many programs /are/ written that way - rushed coding under a manager's whip until the code works well enough to pass some basic tests, then it is shipped to end users. Documentation, if any, is written afterwards with barely a nod towards a specification. The /correct/ way to write code is to specify first (as formally and thoroughly as appropriate for the project), and have everyone agree that the specification fulfils the requirements for the program and that it is feasible to implement in practice. /Then/ start writing code. If the specification is user readable, then it forms the basis for the user documentation - if not, then user documentation can be written before, during or after code development. For a living and evolving project like GCC, this all works in lots of small steps and in practice changes to the code and changes to the documented specifications get committed together, to keep them synchronised. But it is always logically a documented feature and code that implements that specification. (The specification can be a bug report, not just the user documentation.) Attempting to do what you describe - look at the behaviour of gcc in practice, document it and call it the specification - would be insane. I've already tried to explain on this thread how the logical consequence of such ideas is total stagnation of the gcc development. Look at the bugzilla database for GCC - it is /huge/. Every (valid) bug there is a case where GCC does not do what it was supposed to do - what it is /documented/ to do. You would have the GCC folks spend their time updating the documentation to redefine these bugs as previously undocumented features, rather than fixing the bugs in the code, and requiring all future versions of gcc to maintain bug-for-bug compatibility with the older versions. Or could it be that you think this only applies to the features that /you/, personally, want to keep? Sod the rest of the world, as long as /you/ don't need to fix your code? I've come across a fair number of C programmers with your attitude before. Generally they don't realise the consequences of their desires, or how limiting they are. They think they are fighting on behave of others in the same position, arguing that they should be able to continue to rely on undocumented and unwarranted behaviour that has worked before. It sounds reasonable, until you look at what it actually implies - and until you consider all the other groups who also want to rely on /different/ selections of undocumented and unwarranted behaviour. And then, of course, there are all those C programmers who try hard to stick to actual documented and warranted behaviour, and would like the best warnings and development aids to help them write good, correct code, and who then want the results to run as efficiently as possible. The irony is that the people who want their compiler to behave as it always has (for their particular type of code, and their particular unwritten ideas of how to behave) usually complain loudest about GCC. And GCC is, of all the compilers I have used, the best at having /documented/ flags to give these people exactly what they are looking for. For some, it is "-fwrapv", others "-fno-delete-null-pointer-checks", and others it is "-Wno-implicit-function-declaration". David