From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15568 invoked from network); 5 Jul 2021 02:37:59 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Jul 2021 02:37:59 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 5D5739CA3A; Mon, 5 Jul 2021 12:37:56 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 341B39C9F1; Mon, 5 Jul 2021 12:37:01 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ccil-org.20150623.gappssmtp.com header.i=@ccil-org.20150623.gappssmtp.com header.b="wPVtQy2p"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 72A7A9C9F1; Mon, 5 Jul 2021 12:36:59 +1000 (AEST) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by minnie.tuhs.org (Postfix) with ESMTPS id B56009C9F0 for ; Mon, 5 Jul 2021 12:36:58 +1000 (AEST) Received: by mail-qt1-f174.google.com with SMTP id h2so3149313qtq.13 for ; Sun, 04 Jul 2021 19:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FXUbfrAhkjti0ewuLyyrsscgwQdw32FMAZdNZ5G2MA4=; b=wPVtQy2pzD3eT1UXxx0qU8eutdksdNEKM7NFvDt7qcVQE8mPLF03HkmnZFCO2U/+Rx 56riKmM37Uz7Lb5To5MmO3Hi8yhwGV9/ykmCdPnwDGJAOlQDfqC3Nl6seJu9g44GcaEh Z9VHnxQkEIOaeJewY4oaMW7TSH67t45fDwASmPTDwkzvzgfWHmH6OB+BsITIQAaiGayP /f6xkPebeqGF1klvphC7jQua0tKPjBW/WOnNGVQ9utT+HzlF9FgxrDaRA1VdRzqrFI+Z c7hzYNDZWbO8LFAsmUIKYAfANPMmvep05WEWFGb2zrzC3D4po51TDpv9jtjC22ghWbbD Do5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FXUbfrAhkjti0ewuLyyrsscgwQdw32FMAZdNZ5G2MA4=; b=G3EO9rP/YUJTz1RwYLPjiemsZ1ixUWFWnHrhLMOx9BpPB/UZhBEQhuV6xk5mDFgVjJ FDajdk9OaktNXg6+YyP96VL8q3ioGwKQZ+sowG23I3ym4Ve1zNkzDou7MLSzGEfKmX19 pXjFJCLZTJ0c5aG3s/Ti6bedrCApbhsKWKxG10ATMB0BVLTKJj0ku/yY9eiIcsEVSMIO JDIpCo+rCe0UYNOqTssLJq0LxQN1tdLHv+XtXWl2tjxTCNmZ1eJTgx9a8nasaixAVW33 grWhtaPW1+aE0EIgS9UAaOmntPZ+YsO6JKnRQ6Sv/PW+3KW7ZqSzumO4AkLxnBdeeHMv 5qLA== X-Gm-Message-State: AOAM532/8wpO7ZjVe7dgklMSsveYpc8hQjOH2v9TZ1SpPtlPucuHf5zn Fen9dcrfneT9/asv9OhL3MbUPKUa4HMcQY6UPy2FQQ== X-Google-Smtp-Source: ABdhPJyhvAlVSA0jUQ5PLNdKQ0rzkny2U/yxRxMRWZDiIXegWmDudZOl/ar87tQJ6KCA8XkY0poV6LKKFz+rOqZX5Ys= X-Received: by 2002:a05:622a:c2:: with SMTP id p2mr10996654qtw.83.1625452617576; Sun, 04 Jul 2021 19:36:57 -0700 (PDT) MIME-Version: 1.0 References: <20210702213648.GW817@mcvoy.com> <20210705002119.GL817@mcvoy.com> In-Reply-To: <20210705002119.GL817@mcvoy.com> From: John Cowan Date: Sun, 4 Jul 2021 22:36:46 -0400 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="000000000000dec51005c6572d22" Subject: Re: [TUHS] Is C obsolete? (was Re: [tuhs] The Unix shell: a 50-year view) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000dec51005c6572d22 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 4, 2021 at 8:22 PM Larry McVoy wrote: > We both love C, we are both disciplined enough to write > maintainable/extendable code in C, it works for us. We really clicked > over our love of C. > Are you really sure that all the C code the two of you have written in your careers carefully avoids all 191 kinds of undefined behavior in C99 (the number has grown since then)? Give me leave to doubt it. Consider this example from an earlier version of the Linux kernel: static void __devexit agnx_pci_remove (struct pci_dev *pdev) { struct ieee80211_hw *dev = pci_get_drvdata(pdev); struct agnx_priv *priv = dev->priv; if (!dev) return; ... do stuff using dev ... } The trouble here is that dev is used before it is checked for being a null pointer. In Java, you'd have a NullPointerException. In C, "gcc -O2" will make this analysis: Case 1: dev == NULL. This is undefined behavior and the compiler has no obligations. Case 2: dev != NULL. Since dev can't be null (the compiler always assumes the programmer did not intend to use UB), the check can be removed. The result is that there is no check for NULL in either case, the compiler is silent, and since this is the kernel, dereferencing NULL probably pwns your system. So whereas things that were technically UB used to work more or less as you'd expect them to, nowadays they work as *nobody* expects them to. This is the result of the three values of C programmers: (1) fast execution, (2) fast compilation, (3) I lied; there is no (3). And as optimizers get better and better, the number of UB-related disasters increases. (The same is true for C++ compiler developers, except that they sometimes prioritize (2) over (1) because benchmarks.) > If I had infinite energy and money, I would fund a dialect of C that > made it more useful. See , about how an attempt to reduce the amount of UB int C failed because nobody could agree with anybody else on what changes to make. > For all its faults, C++ is the closest to a modern language that sort > of fits with what I want > C++, is it? C++2011 has 203 UBs. --000000000000dec51005c6572d22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Sun, Jul 4, 2021 at 8:22 PM Larry McVoy <lm@mcvoy.com> wrote:
=C2=A0
We bot= h love C, we are both disciplined enough to write
maintainable/extendable code in C, it works for us.=C2=A0 We really clicked=
over our love of C.


Conside= r this example from an earlier version of the Linux kernel:

static void __devexit a= gnx_pci_remove (struct pci_dev *pdev)
{
=C2=A0 struct ieee80211_hw *d= ev =3D pci_get_drvdata(pdev);
=C2=A0 struct agnx_priv *priv =3D dev->= priv;

=C2=A0 if (!dev) return;
=C2=A0 ... do stuff using dev ...=
}


Case 1: dev =3D=3D NULL.=C2=A0 = This is undefined behavior and the compiler has no obligations.

Case 2: dev !=3D NU= LL.=C2=A0 Since dev can't be null (the compiler always assumes the prog= rammer did not intend to use UB), the check can be removed.

The result is that ther= e is no check for NULL in either case, the compiler is silent, and since th= is is the kernel, dereferencing=C2=A0NULL probably pwns your system.=C2=A0 = So whereas things that were technically UB used to work more or less as you= 'd expect them to, nowadays they work as *nobody* expects them to.
<= /div>

This is = the result of the three values of C programmers:=C2=A0 (1) fast execution, = (2) fast compilation, (3) I lied; there is no (3).=C2=A0 And as optimizers = get better and better, the number of UB-related disasters increases.=C2=A0 = (The same is true for C++ compiler developers, except that they sometimes p= rioritize (2) over (1) because benchmarks.)
=
If I had infinite e= nergy and money, I would fund a dialect of C that
made it more useful.

S= ee <https://blog.regeh= r.org/archives/1287>, about how an attempt to reduce the amount=C2= =A0of UB int C failed because nobody could agree with anybody else on what = changes to make.
=C2=A0
For all its faults, C++ is the closest to a modern language t= hat sort
of fits with what I want=C2=A0

C++, is it?=C2=A0 C++2011 has 203 UBs.
--000000000000dec51005c6572d22--