From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 107EF3858D1E for ; Fri, 2 Jun 2023 03:05:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 107EF3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-3f6cbdf16d2so14696755e9.2 for ; Thu, 01 Jun 2023 20:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685675142; x=1688267142; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=31Q0RR7lzIDlN64RZ9LmR+3bCXXknKVoLmXsza5RgOw=; b=fQ3+I8lnLP8821I+PsbtQ3y9d7PdDk4+38tp1QJQ8ppLDXqIuBzPts5FDdZsCIX+lr HyCxqsE2357TE9Q0Wyf3eJqp50JvtE4OBYoDguEuk26HI6OhInlg4zBGgXjM4voKO0IM HOFBrzXE3OQKJE5Nx5XoL91JoIVmAk0DRjTgqzwWJuVgRxL0YduKwdMddJ5yVkkiq21W PmEYeYG8hpxjWe1EaAlzFOmu0lkDHi6ztg5VH0fuTlfYV3j1HBd1evXyBjZFXBY9AyZH vhR9bWWJYwSGbN2mUsFPdUvkQ1gbz4mdHcv5f2ry/ZbA2VQI0SDF2hWM015qhiQoFDxx ycpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685675142; x=1688267142; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=31Q0RR7lzIDlN64RZ9LmR+3bCXXknKVoLmXsza5RgOw=; b=mBNAUlP2iqOYIsnUPdvtKxIG04S5sqt5kgHNE78C5W6YoFHgkoUxmP9mLJ4M8FwdZK Zi/mG57F9N09cec1TjueN7+qOTGYCuVd+plAYW3RFLa5K6B//ZE9Zr12YGSGjFlW0j+U Rt7fdMrWO1+m3mM/2YbZcPWK4hzGoIciLp0D1cAlYzqPgTRaEOGmtKbr+Y3p4re4cLKZ 5YdNpuHxrVdeQgslqbpKEy9vF5xbjOo4RaJ00AqzbStWP13/xwhbiTM8ClQw6ZrRaj2a NJrpaCkIhvRIxOHFTC6+k1+j1pVmM8UJoxXZ+/qiakMHBRsGw+xRRN5OFE6qgSE1wD0s 5tvw== X-Gm-Message-State: AC+VfDxcHeRRauUbLqRQAjIEOypWSIvAZ1VnYNUtnSDLT5y7Y9uffpjs 8Xra5SVfG2qTDIN7LWlrxJU= X-Google-Smtp-Source: ACHHUZ4/X6lGMls4Ty/ZrqO0mkp95PKBkyG6zzuN+R//UAdRF9xjSqWoHvr2dlLfZbpwmrQApao75g== X-Received: by 2002:a7b:c403:0:b0:3f4:2174:b29c with SMTP id k3-20020a7bc403000000b003f42174b29cmr692507wmi.20.1685675141509; Thu, 01 Jun 2023 20:05:41 -0700 (PDT) Received: from [192.168.0.160] ([170.253.51.134]) by smtp.gmail.com with ESMTPSA id l5-20020a7bc445000000b003f6042d6da0sm456656wmi.16.2023.06.01.20.05.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Jun 2023 20:05:40 -0700 (PDT) Message-ID: Date: Fri, 2 Jun 2023 05:05:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: Deprecation of C89? To: Ian Lance Taylor , Florian Weimer , Sam James Cc: gcc-help References: <18b9bd78-8617-9c96-8290-2d985b326295@gmail.com> Content-Language: en-US From: Alejandro Colomar In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------cUay5FpNG1NoG1OPYs1HyXv3" X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,IMAGE_ATTACHED,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------cUay5FpNG1NoG1OPYs1HyXv3 Content-Type: multipart/mixed; boundary="------------be5nZGEmci0Z5Ei3P8i8rbV7"; protected-headers="v1" From: Alejandro Colomar To: Ian Lance Taylor , Florian Weimer , Sam James Cc: gcc-help Message-ID: Subject: Re: Deprecation of C89? References: <18b9bd78-8617-9c96-8290-2d985b326295@gmail.com> In-Reply-To: --------------be5nZGEmci0Z5Ei3P8i8rbV7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ian, Florian, Sam, On 6/2/23 02:26, Ian Lance Taylor wrote: > On Thu, Jun 1, 2023 at 3:52=E2=80=AFPM Alejandro Colomar via Gcc-help > wrote: >> >> I was just wondering if there are any plans to drop support of C89 (an= d >> gnu89) at any point in the future. I didn't find any such discussion = in >> the mailing list. >> >> That change would probably break very ancient code (implicit int, impl= icit >> function declarations, ...), but such code is very likely to have been= >> updated in the last several decades to be at least compatible with C99= , so >> I don't expect that much breakage. >> >> Most big projects have already migrated, with only a few still resisti= ng >> (curl comes to mind). But again, I think they use a subset that would= >> compile under C99 with little or no modification. >> >> I guess supporting C89 keeps a lot of extra complexity in GCC's source= code >> itself, and maybe even hinders some optimizations. >=20 > We just had a long thread in which several people objected strongly to > just making the use of certain old C constructs an error by default > (https://gcc.gnu.org/pipermail/gcc/2023-May/241264.html). If there > are strong objections to making these constructs into errors, I think > there would be even stronger objections to removing support for C89 > entirely. 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. 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'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. 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. 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. 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. 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]: 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 >=20 > Ian --=20 GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5 --------------be5nZGEmci0Z5Ei3P8i8rbV7-- --------------cUay5FpNG1NoG1OPYs1HyXv3 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE6jqH8KTroDDkXfJAnowa+77/2zIFAmR5XH0ACgkQnowa+77/ 2zKzuA//fJqq+7mR34xOX1RflnlJkVDtbbYp7QcvH3ssVFt+GSDZoNp/hiN2Vj3C b6shUbdEpnT+rBS1vw/bavIsZ/LXd76R/E0v7kSGhgqz4y9SncBresk6SoKaYdbY v++6Ut5+qkVjorg+RmV9ZbgdpnbHwIG5bhdo5l6SFRWQ9Ly44jZ9Tt99i4lhfPFM cyznlupkWoF7ak58peoJSXB3bGVs8RUX6/x69AlvL5FPtzEctVn7yM2JiuqkE6+O s+OgtdivqTe4ffzeOu7MHqKziU130FnBM/sIkeMfnOcCKnssiUiaZZbmW70/ODxI rVt8/v4ZnDgrQsHXwhowQ/rC8CCPaeqwgS3Mgqpj1iiItu0I54GzjHa2b5CMArpU cn3g3+BowQ6LAcXumzBLZyAolfZx7DG+WsEfZnQC9OrXNDDkmSPhnc/zHJNbkwNQ xoiAbumKKJ/uqCUmkQe5Q8Tqmnwxxt8Z/q+5YHB4ihyBGFWT7MIV5Hun7bXy7eNN 9A/W+zGpS9dj/sthF+jgBhAozBqzMu1ZBh83O81wt0WfwMVIP4c2ZSkHK82i/CO8 bWrZl8r/gUOchpfVwpsvpNQkUa6Ah11gj5I9dvIaG9A8RuriSERSr/2uEC64o+RV FFg0iqGgCj7906/OCTH1ekK+CjmA0oUNjH+5ibQl4u/CZuMpsHA= =MjEX -----END PGP SIGNATURE----- --------------cUay5FpNG1NoG1OPYs1HyXv3--