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.6 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 [IPv6:2600:3c01:e000:146::1]) by inbox.vuxu.org (Postfix) with ESMTP id 860522CA2C for ; Sun, 29 Sep 2024 18:56:33 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 41B2443145; Mon, 30 Sep 2024 02:56:28 +1000 (AEST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) by minnie.tuhs.org (Postfix) with ESMTPS id 44D3343110 for ; Mon, 30 Sep 2024 02:56:23 +1000 (AEST) Received: by mail-vs1-xe34.google.com with SMTP id ada2fe7eead31-4a3a34b3a5aso583659137.1 for ; Sun, 29 Sep 2024 09:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dartmouth.edu; s=google1; t=1727628982; x=1728233782; darn=tuhs.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=zUCsAfTNuWeTsEfwcTJmd03qxP1NQhuG1vpO0xFgsG8=; b=H/nIgHKcjXv4EVVe3/p09tjvMQXu6XYiZ+5BhLLNetebpa2VYg0jBcJPSAVKbkDj1g 2lf6URbodl4eld15C93P+EiT+5xzT/zFtfwvgSZWFNRAZIx036J3ZyZVa8aUSNyR1xy/ WKFGXlFQ7mLxhJC5pQMmmBX6YgCDo5ZA8sDjvgjDBa/j+m1BpOgd4jUdDAaN0xOLPUkk tnetpDJB/I+bQ2IhmGe+AQJbd8w6txeYMzq5SyinUN7ZZeitKv8kMTT6HPZlKg5nhE5g YVq5CxI0LbzThvlJwZX0h6E4uVPpkuHbnRDVEbPO2rXOPtgWhf9xg7B8TTNLFA7At/aR gClw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727628982; x=1728233782; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zUCsAfTNuWeTsEfwcTJmd03qxP1NQhuG1vpO0xFgsG8=; b=Y3kWT7I2wjWhOLszLlAp4t+sO/+65DSlSQquawk9rKSOufi8Ync+alOIwGcrptYAQA yHU3C2hz4zniLOHGTsszlJSiVYBTyw6jecZAEWDSE/XaFA2dqNzLVafXojTNDxfQgZXc B5m86lG08h5LBIYq9ZVm85ArFpFNZfngJQQszv4q+nOcZq2SY2/D5ij6pHGms7siTlCh 2dbHnYHbN2eCUKhIPJxPbYjgiBo1YNHSoaNNIhQTldVze9lZKtEoDF5Ve8mHsUQuA1d1 1CIu4OeVdOUNtO1fFqOQwnyibBq5KUplSCLeJDH+mO3glTqfyDmYsp5NF69m0+xi8lJC gr4g== X-Gm-Message-State: AOJu0Yxt0WTilR+YhSPdlx5poKFrnWLZz6BupkJHDraJQIJe8CoiyvIm 0+xYX3rGeZuQe2V1MVAM7aW99Sq9sEkAnMfxe4IOXp2ERDVZGn4FQpMWwUxg+DAO0uiM3DqOBTR cMDolmZ0GFKXgm+GTvdUYHkDTXQgn5PzbCMStkH/5RJte4soUmgw= X-Google-Smtp-Source: AGHT+IGEs6HjjEOB4EGKBSmjqOVFUoCHqnIKLMlgFm3D1zNtErU3/mvsmUdCUAqUnDHBiUCqDgrP8Q6Mu86WAz0fHxA= X-Received: by 2002:a05:6102:3746:b0:493:e66a:793f with SMTP id ada2fe7eead31-4a2d800a618mr6215853137.23.1727628982156; Sun, 29 Sep 2024 09:56:22 -0700 (PDT) MIME-Version: 1.0 From: Douglas McIlroy Date: Sun, 29 Sep 2024 12:56:07 -0400 Message-ID: To: TUHS main list Content-Type: multipart/alternative; boundary="000000000000c917fc062344f7cf" Message-ID-Hash: W3AGMIRLQQI5QKPXOUDN2UFRDVF3MU66 X-Message-ID-Hash: W3AGMIRLQQI5QKPXOUDN2UFRDVF3MU66 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: --000000000000c917fc062344f7cf Content-Type: text/plain; charset="UTF-8" >>> malloc(0) isn't undefined behaviour but implementation defined. >> >> In modern C there is no difference between those two concepts. > Can you explain more about your view There certainly is a difference, but in this case the practical implications are the same: avoid malloc(0). malloc(0) lies at the high end of a range of severity of concerns about implementation-definedness. At the low end are things like the size of ints, which only affects applications that may confront very large numbers. In the middle is the default signedness of chars, which generally may be mitigated by explicit type declarations. For the size of ints, C offers guardrails like INT_MAX. There is no test to discern what an error return from malloc(0) means. Is there any other C construct that implementation-definedness renders useless? Doug --000000000000c917fc062344f7cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>> malloc(0) isn't undefine= d behaviour but implementation defined.
>>
>> In modern C= there is no difference between those two concepts.

> Can you exp= lain more about your view=C2=A0

Th= ere certainly is a difference, but in this case the practical implications = are the same: avoid malloc(0). malloc(0) lies at the high end of a range of= severity of concerns about implementation-definedness. At the low end are = things like the size of ints, which only affects applications that may conf= ront very large numbers. In the middle is the default signedness of chars, = which generally may be mitigated by explicit type declarations.
<= br>
For the size of ints, C offers guardrails like INT_MAX. There= is no test to discern what an error return from malloc(0) means.

Is there any other C construct that implementation-definedn= ess renders useless?

Doug

--000000000000c917fc062344f7cf--