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.8 required=5.0 tests=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 [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id B70FC2241B for ; Mon, 30 Sep 2024 22:12:05 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id DF184436FB; Tue, 1 Oct 2024 06:12:04 +1000 (AEST) Received: from zimbra.anteil.com (mail.anteil.com [198.22.99.76]) by minnie.tuhs.org (Postfix) with ESMTP id 9D47A436FB for ; Tue, 1 Oct 2024 06:12:01 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.anteil.com (Postfix) with ESMTP id 2516B3EAED2; Mon, 30 Sep 2024 16:12:01 -0400 (EDT) Received: from zimbra.anteil.com ([127.0.0.1]) by localhost (zimbra.anteil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbJthJ0OhgYN; Mon, 30 Sep 2024 16:12:00 -0400 (EDT) Received: from zimbra.anteil.com (zimbra.anteil.com [192.168.1.22]) by zimbra.anteil.com (Postfix) with ESMTP id 608A51089C; Mon, 30 Sep 2024 16:12:00 -0400 (EDT) Date: Mon, 30 Sep 2024 16:12:00 -0400 (EDT) From: Jim Capp To: Rich Salz Message-ID: <5182549.12624.1727727120300.JavaMail.root@zimbraanteil> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12623_6592605.1727727120299" X-Originating-IP: [192.168.100.112] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - FF3.0 (Mac)/6.0.7_GA_2473.UBUNTU8) Message-ID-Hash: FR6VWSM43D63IUXTP26DIH52ITBHXR3T X-Message-ID-Hash: FR6VWSM43D63IUXTP26DIH52ITBHXR3T X-MailFrom: jcapp@anteil.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 CC: Douglas McIlroy , Computer Old Farts X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_12623_6592605.1727727120299 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Moving to COFF ,.. From: "Rich Salz" To: "TUHS main list" Cc: "Douglas McIlroy" Sent: Monday, September 30, 2024 4:03:15 PM Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum) On Mon, Sep 30, 2024 at 3:12 PM Steffen Nurpmeso < steffen@sdaoden.eu > wrote noone ever told them that even the eldest C can be used in a safe way; Perhaps we have different meanings of the word safe. void foo(char *p) { /* interesting stuff here */ ; free(p); } void bar() { char *p = malloc(20); foo(p); printf("foo is %s\n", p); foo(p); } Why should I have to think about this code when the language already knows what is wrong. No one would make the claim that programming in machine "language" is safe. No one would make the claim that programming in assembly "language" is safe. I've always viewed C as a portable assembler. I think the real issue has nothing to do with the "safety" of C, but rather the "safety" of your-choice-of-C-libraries-and-methods. My $.02 Jim ------=_Part_12623_6592605.1727727120299 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >
Moving to COFF ,..

<= b>From: "Rich Salz" <rich.salz@gmail.com>
To: "TUHS mai= n list" <tuhs@tuhs.org>
Cc: "Douglas McIlroy" <douglas.m= cilroy@dartmouth.edu>
Sent: Monday, September 30, 2024 4:03:15= PM
Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maxi= mum)



On Mon, Sep 30, 2024 at 3= :12=E2=80=AFPM Steffen Nurpmeso <steffen@sdaoden.eu> wrote
noone ever told them that even the eldest C can be used in a safe
way;
 
Perhaps we have different meanings o= f the word safe.

    void foo(char = *p) { /* interesting stuff here */ ; free(p); }
  =   void bar() { char *p =3D malloc(20);
   &nb= sp;    foo(p);
      = ;  printf("foo is %s\n", p);
     &= nbsp;  foo(p);
    }
Why should I have to think about this code when the language = already knows what is wrong.

No one would mak= e the claim that programming in machine "language" is safe.

No one would make the= claim that programming in assembly "language" is safe.

I've always viewed C as a= portable assembler.  I think the real issue has nothing to do with th= e "safety" of C, but rather the "safety" of your-choice-of-C-libraries-and-= methods.

My $.02

Jim

------=_Part_12623_6592605.1727727120299--