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_INVALID,DKIM_SIGNED, 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 2D45C2C9CF for ; Sat, 28 Sep 2024 15:34:48 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id D4E22421BD; Sat, 28 Sep 2024 23:34:41 +1000 (AEST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) by minnie.tuhs.org (Postfix) with ESMTPS id 648F3421B8 for ; Sat, 28 Sep 2024 23:34:31 +1000 (AEST) Received: by mail-vs1-xe2b.google.com with SMTP id ada2fe7eead31-4a3ac30bd7cso189788137.3 for ; Sat, 28 Sep 2024 06:34:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dartmouth.edu; s=google1; t=1727530470; x=1728135270; darn=tuhs.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Rz6j9Xo1ICrDQSOTaIyKlEiqJZIBl3UEiVTP+4WfIrU=; b=nUvqHzYYO5W5E1GZmi3GkqZuBIPbSui9e3NlzeME/fLSWRWpv/670q/KHiFH4g5zme hBTuuuric/9XizFdQYgO0hzvHua2Xtwi1cuSkb+9BEgxr/nKigXcrktCksoIdH+a0lCJ 2tJuGOlxWZgHOks23ggnpdvfjLE/tn8KSEbG2vBrFqHpEe0zFzLzh245c0fQfUMVX4f2 eLojcw6jdW7lsaY4DDCTgLEzoMkoH04Vuekd63IMdOgTKmOhlcMtHFNemKgi2tRFRVKb QWhhBS7UyZPptmRb6rp5FSAQQP2w0U+TvmUbfRTx003mQIcvjfwAwbUsHm/KWIp+EU/Q YnFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727530470; x=1728135270; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Rz6j9Xo1ICrDQSOTaIyKlEiqJZIBl3UEiVTP+4WfIrU=; b=vEVZ9o6xpRAsalUc6BiEnQ3OKfrxF4FlKb0hLzavW9697N5VzZ+9rq0/FcyStB5lGw Rh29+ONVibGnHUco+JWaqXFlQfDaEL8CcUJlLZ9zA8qyC5cbf4D/Xu1NcrJXDj1LtPsC 3YWFuUosw3dv8tjhQSaBpiBbCB0d42aQgvYHlkG2sacjwXTtVJVJ/nTPMGrQFLfT67VN ZGqzT5x4j7gE1GRABHCrXA+PkjAtxtTyLsgFdMNO7ncKeQ1O7jVntAtRcWE9ncb7/Z+M 83mUjpk0/MGa3/ugrN4pp3kCXQM/FCAUleP2vGxe/4maqEilL6Z30Y41JaAGAinKhi0s XJ2w== X-Gm-Message-State: AOJu0YwuIzbU7VNFyuZn35Bb+zEwL2hsowBPxxN6z/NLPZM3TnYinYp9 E1f66ZNlha9m+DWJ3dGJWzfrnndZnjs8KRX8usJly9T4ElSeh6rHVXJLT+UQSdecE8BDx4yJP27 azCHCD6d9yOuHf/6BFubhE3Vix+wsOgBjxtO5qaVCpkNRHolNmC4= X-Google-Smtp-Source: AGHT+IHiYypcKafAgvy0DRYJwYIXJQ5HcKXNxdzuV/RqibfXkw9QQpp5wnrzszqslCe5kgDnLCbUoxQkFHUR03J5jmo= X-Received: by 2002:a05:6102:441f:b0:49f:b974:5a4b with SMTP id ada2fe7eead31-4a2d7f56cb2mr5389920137.16.1727530470220; Sat, 28 Sep 2024 06:34:30 -0700 (PDT) MIME-Version: 1.0 From: Douglas McIlroy Date: Sat, 28 Sep 2024 09:34:14 -0400 Message-ID: To: TUHS main list Content-Type: multipart/alternative; boundary="00000000000004402906232e08e0" Message-ID-Hash: JIG5UZ4ZJV7JOUTJKNY2Z5ZUKQC5E7SH X-Message-ID-Hash: JIG5UZ4ZJV7JOUTJKNY2Z5ZUKQC5E7SH X-MailFrom: douglas.mcilroy@dartmouth.edu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; 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: Minimum Array Sizes in 16 bit C (was Maximum) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000004402906232e08e0 Content-Type: text/plain; charset="UTF-8" > C's refusal to specify dynamic memory allocation in the language runtime > (as opposed to, eventually, the standard library) This complaint overlooks one tenet of C: every operation in what you call "language runtime" takes O(1) time. Dynamic memory allocation is not such an operation. Your hobbyhorse awakened one of mine. malloc was in v7, before the C standard was written. The standard spinelessly buckled to allow malloc(0) to return 0, as some implementations gratuitously did. I can't imagine that any program ever actually wanted the feature. Now it's one more undefined behavior that lurks in thousands of programs. There are two arguments for malloc(0), Most importantly, it caters for a limiting case for aggregates generated at runtime--an instance of Kernighan's Law, "Do nothing gracefully". It also provides a way to create a distinctive pointer to impart some meta-information, e.g. "TBD" or "end of subgroup", distinct from the null pointer, which merely denotes absence. Doug --00000000000004402906232e08e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> C's refusal to specify dynamic m= emory allocation in the language runtime
> (as opposed to, eventually= , the standard library)=C2=A0

This com= plaint overlooks one tenet of C: every operation in what you
call= "language runtime" takes O(1) time. Dynamic memory allocation
is not such an operation.

Your hobbyhorse = awakened one of mine.

malloc was in v7= , before the C standard was written. The standard
spinelessly bu= ckled to allow malloc(0) to return 0, as some=C2=A0
implementatio= ns gratuitously did. I can't imagine that any program
ever ac= tually wanted the feature. Now it's one more undefined
behavi= or that lurks in thousands of programs.

There are = two arguments for malloc(0), Most importantly, it caters for
a li= miting case for aggregates generated at runtime--an instance of
K= ernighan's Law, "Do nothing gracefully". It also provides a w= ay to=C2=A0
create a distinctive pointer to impart some meta-info= rmation, e.g.
"TBD" or "end of subgroup", dis= tinct from the null pointer, which
merely denotes absence.
<= div>
Doug
--00000000000004402906232e08e0--