From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 707F622304 for ; Mon, 20 May 2024 18:07:11 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id BB99843B3A; Tue, 21 May 2024 02:07:06 +1000 (AEST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by minnie.tuhs.org (Postfix) with ESMTPS id 11A1343B39 for ; Tue, 21 May 2024 02:07:01 +1000 (AEST) Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1e3c3aa8938so79727125ad.1 for ; Mon, 20 May 2024 09:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716221220; x=1716826020; darn=tuhs.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=hat725maPFmuKWWfXEB0+iIKmQYpxJrgVh++0iL8ARc=; b=I0ueN8rWK3Ui7MjpWaF/+TpAwNjdAoTrbIpD064WTPNA/C1bkEKT+ifdNRIsz+Kxa0 FV3mcPv9sbpit9w7FrpguW9i1HDS6q1XkYtB4ccOMwYMI1Fug4Qqx+jZwvcuPEW7CSKf fiaqBpu9LFtExZqAXcAKZKqBRHcao1vtbAkzKptCsyfh0p0VvjCiALDhuMqU2/qOAAsj kCvVlXm9SvhSUsJTwJcdQaK4PuuvlQjZorA4EcK1vqnRbsI1hl3M21moF2Mir6uQiytG pbHUeDYdnSsBprwM2Yk1RKM2PYJ8+WDaOaF6eqKvd205G0NE1Uxmd1TJj5aL//O/82PY Qg3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716221220; x=1716826020; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hat725maPFmuKWWfXEB0+iIKmQYpxJrgVh++0iL8ARc=; b=BTjwgQXgOYK2zRYrJHWuIzSefIYhhcj7r43LjwrTAOUu58mEusAkxPW+hAonuKLW2a Csc0IM0clrA9Z5KuYeQU7YiESdYGGOf5CexX0tZoHFXye98v7NvL+ufX7dDem9/cnYY6 wkUPqOf7+89BZYVGSyZUz4qdbJPE+Zr0O+eoKe4Pmvg+JQHXWlieXqZK1xcDOMfWDsLl usfdzBTuPUGi1hGixk/SjmIAyCGMd85SrvEx10X1N2v/K8lJV4HfGerq5NHMyldQMLCB /3gyuX2tWrl/Yi4tss5oArcO1wD81ZpVaKQ6LkUq2USvIL79YDBm+gatUFUnLG/Zror+ Uuwg== X-Gm-Message-State: AOJu0Yzk2Crg2lzMgXQTbJ6z1eQ17gCamjYniurwrbrt9704Sl0pueK5 ZmlEJOd8f9C9XSXL/klJbaXJXeukSJw0/Nqe+HlL9Gp9ScweLQG9zxLNfZmgoyo1GOUdYXst5Ny nGabkZ/8pA7OIMKp4rLKuYoDAwZTBYQ== X-Google-Smtp-Source: AGHT+IEKEZjRi4H2dNpuuGuyqOsuFZuj+0aBJzIu6iNvj2AYRCI3tTpODmSUzNGcrMxae5wvr1M4UCPk5sdxoRGqZk0= X-Received: by 2002:a17:90a:7789:b0:2a5:f70c:9ec6 with SMTP id 98e67ed59e1d1-2b6cc97d18fmr26431567a91.24.1716221220062; Mon, 20 May 2024 09:07:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Winalski Date: Mon, 20 May 2024 12:06:49 -0400 Message-ID: To: TUHS main list Content-Type: multipart/alternative; boundary="0000000000002d96fa0618e4e4a1" Message-ID-Hash: AYJA5R4U73IAAXZDQPRWNEJESMR5OPC2 X-Message-ID-Hash: AYJA5R4U73IAAXZDQPRWNEJESMR5OPC2 X-MailFrom: paul.winalski@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: A fuzzy awk. (Was: The 'usage: ...' message.) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000002d96fa0618e4e4a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 20, 2024 at 9:17=E2=80=AFAM Douglas McIlroy < douglas.mcilroy@dartmouth.edu> wrote: > I'm surprised by nonchalance about bad inputs evoking bad program > behavior. That attitude may have been excusable 50 years ago. By now, > though, we have seen so much malicious exploitation of open avenues of > "undefined behavior" that we can no longer ignore bugs that "can't happen > when using the tool correctly". Mature software should not brook incorrec= t > usage. > > Accepting bad inputs can also lead to security issues. The data breaches from SQL-based attacks are a modern case in point. IMO, as a programmer you owe it to your users to do your best to detect bad input and to handle it in a graceful fashion. Nothing is more frustrating to a user than to have a program blow up in their face with a seg fault, or even worse, simply exit silently. As the DEC compiler team's expert on object files, I was called on to add object file support to a compiler back end originally targeted to VMS only. I inherited support of the object file generator for Unix COFF and later wrote the support for Microsoft PECOFF and ELF. When our group was bought by Intel I did the object file support for Apple OS X MACH-O in the Intel compiler back end. I found that the folks who write linkers are particularly lazy about error checking and error handling. They assume that the compiler always generates clean object files. That's OK I suppose if the compiler and linker people are in the same organization. If the linker falls over you can just go down the hall and have the linker developer debug the issue and tell you where you went wrong. But that doesn't work when they work for different companies and the compiler person doesn't have access to the linker sources. I ran into a lot of cases where my buggy object file caused the linker to seg fault or, even worse, simply exit without an error message. I ended up writing a very thorough formatted dumper for each object file format that did very thorough checking for proper syntax and as many semantic errors (e.g., symbol table index number out of range) as I could. -Paul W. --0000000000002d96fa0618e4e4a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 20, 2024 at 9:17=E2=80=AFAM D= ouglas McIlroy <douglas= .mcilroy@dartmouth.edu> wrote:
I'm surpr= ised by nonchalance about bad inputs evoking bad program behavior. That att= itude may have been excusable 50 years ago. By now, though, we have seen so= much malicious exploitation of open avenues of "undefined behavior&qu= ot; that we can no longer ignore bugs that "can't happen when usin= g the tool correctly". Mature software should not brook incorrect usag= e.

Accepting bad inputs can also lead= to security issues.=C2=A0 The data breaches from SQL-based attacks are a m= odern case in point.

IMO, as a programmer you owe = it to your users to do your best to detect bad input and to handle it in a = graceful fashion.=C2=A0 Nothing is more frustrating to a user than to have = a program blow up in their face with a seg fault, or even worse, simply exi= t silently.

As the DEC compiler team's expert = on object files, I was called on to add object file support to a compiler b= ack end originally targeted to VMS only.=C2=A0 I inherited support of the o= bject file generator for Unix COFF and later wrote the support for Microsof= t PECOFF and ELF.=C2=A0 When our group was bought by Intel I did the object= file support for Apple OS X MACH-O in the Intel compiler back end.

I found that the folks who write linkers are particularly= lazy about error checking and error handling.=C2=A0 They assume that the c= ompiler always generates clean object files.=C2=A0 That's OK I suppose = if the compiler and linker people are in the same organization.=C2=A0 If th= e linker falls over you can just go down the hall and have the linker devel= oper debug the issue and tell you where you went wrong.=C2=A0 But that does= n't work when they work for different companies and the compiler person= doesn't have access to the linker sources.=C2=A0 I ran into a lot of c= ases where my buggy object file caused the linker to seg fault or, even wor= se, simply exit without an error message.

I ended = up writing a very thorough formatted dumper for each object file format tha= t did very thorough checking for proper syntax and as many semantic errors = (e.g., symbol table index number out of range) as I could.

-Paul W.
--0000000000002d96fa0618e4e4a1--