From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by sourceware.org (Postfix) with ESMTPS id 8F4C4385660B for ; Fri, 2 Jun 2023 07:04:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F4C4385660B Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=aarsen.me Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aarsen.me Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4QXYs337Mzz9sbB; Fri, 2 Jun 2023 09:04:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1685689463; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=daKa98Yq79ld+ZorQOVd9hM3iYoca+X14UDh5bV6pV0=; b=AdrdqcJ3c2ljIp9fJV62W94SG4GWJYDLeq8lompjNp2iTDY5T1SS9IS7x+Q/5IoiAGKUT5 bB6oQK8d/SJLhc9LkLZzxd/lFvqLYhTJXuojG2uEjhZtXB4CRrGQmO9iC2eb1ah5nPqozJ 2yqjZtHKs81i4iqOebCfoyH19kljNNKag6EN3aIU4LFvt6A3eiz2Ghng+/ZwIBr7s5No/Z Nay2M1r+zeiem8P1Vb/SPg0ofFlQ71lq3OcFm727xaYhJM+cqAZ4UL4nV5JblOhdrvCClK qaTAilZJnXhEOPXX+Tf5ZegsjnshUaIgzi3c78lnhlcgBvCPT9FwFkcm0waiug== References: <18b9bd78-8617-9c96-8290-2d985b326295@gmail.com> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Alejandro Colomar Cc: Ian Lance Taylor , Florian Weimer , Sam James , gcc-help@gcc.gnu.org Subject: Re: Deprecation of C89? Date: Fri, 02 Jun 2023 08:37:30 +0200 In-reply-to: Message-ID: <865y869wgc.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4QXYs337Mzz9sbB X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,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: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Alex, Alejandro Colomar via Gcc-help writes: > Thanks for pointing to that. I'll +1 to Florian's proposal, and add > something. > > C89 is basically C99 with added broken stuff such as implicit int, > implicit functions, and no stdint. Not much more than that. gnu89 > also includes the "other" inline. I would be happy with adding an > optable-out error for those as a first step, and one or two releases > later completely kill C89. I don't think killing C89 is very useful. As you said, it's not too different to C99; however, we shouldn't be promoting its deficiencies into newer language standards (but you've seen the thread on that :-) ). > About doing something in the distros if upstream GCC doesn't do it: > I believe breaking a package in Fedora, Debian, and Gentoo will be > enough that most upstream projects will fix their bugs. I don't > think packagers will have to do it themselves. I believe that > patching distro's GCC to enable -Werror=3D... would already be a great > step. I'm not sure it's a good idea to change behavior away from upstream decisions in our downstream. Keep in mind, though, that we (Gentoo) have CI infrastructure and developers already testing with stricter flags. > I've have to deal with programmers that lived in a cave for the last > 30 years, and believe that there's no issue with having a pointer 2 > past the end of an array, as long as you "restore" it by subtracting > 2 afterwards, and worse stuff, because it just works. As was said in > that other thread, if GCC generates "working" code, they'll defend > that code. Having an error by default for the most broken stuff > would probably help them see the light. C89 (similar to GNU C 89) doesn't prevent writing correct code, though, even if it lacks some facilities. > The only issue which can't be solved is compiling unmaintained > software that was written 30 years ago. But if one is doing that, > they probably also have a system with a compiler written 30 years > ago. I don't see why anyone would want to compile K&R code in > bleeding edge systems. A VM is always available. They can even > get an old GCC version. Sadly, some modern codebases are C89 (libvp8 comes to mind.. don't ask, because I don't know why either ;) ). But, old codebases can be written in a way which is correct, so I don't see why removing C89 would help there. > Another point is that since this year, companies are already > stopping using C because of being unsafe. I don't believe C being > unsafe, but C89 definitely *is*. I don't think keeping it around is > doing anyone a favor. In my job, they're requiring Rust for newly > written programs. I hope we help prevent continuing down that road. I'm afraid this won't convince folks. People treat C++ the same as pre-standard C, even though it's quite easy to write code that prevents errors in C++ in a way similar to Rust. I also don't see a significant difference between C89 (and some -Werror flags) and C99 in this regard. > Florian, Sam, may I suggest that you patch/configure your GCC to have > those few -Werror=3D... enabled by default? After one release with > that in Fedora and Gentoo, I guess it will be easier to merge it into > upstream GCC. And a similar thing but a year later could be done > with C89. We'd like to do this in GCC 14 anyway (in 99+). > I already ported shadow[1] from pre-C89 code to require C11 and > POSIX.1-2008, and it was relatively easy. I am now porting zlib[2] > from pre-C89 code to require C89 (I wish I could raise that at least > to C99, but I'm not sure how much receptive the maintainer will be > without the compiler setting on fire). > > [1]: > > > > > > > > > > > Thank you! This work is quite valuable. I do suspect a more conservative response from zlib, though. > POSIX.1-2008 was a bit more complex, but C99 should be trivial. > > The result was a much cleaner code base, with a lot less cpp(1), > and a net removal of thousands of lines of code. While cleaning > up the code, several hidden bugs were made shallow, and thus > fixed. > > [2]: > > Thanks! > Alex I'd like to note that I'm not advocating for the prolonged use of C89, just for keeping compatibility where the cost is low (and I strongly oppose forward-porting the messy parts of C89 into C99+ as GCC has done so far). (PS: this topic is likely more appropriate for gcc@gcc.gnu.org) Have a lovely day :) =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZHmUc18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTwDABAL8XUqxLdlwhrP8YAb2qBXnKqo0hQFDsrQ6/ zl7SEnNdAQCzRuSShVHLfCGSksnUhP6MJ3v+tt/VuEtgbfxIozypAw== =ZaP6 -----END PGP SIGNATURE----- --=-=-=--