The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Ralph Corderoy <ralph@inputplus.co.uk>
To: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
Cc: TUHS <tuhs@tuhs.org>
Subject: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)
Date: Sun, 29 Sep 2024 22:24:35 +0100	[thread overview]
Message-ID: <20240929212435.6445920340@orac.inputplus.co.uk> (raw)
In-Reply-To: <CAKH6PiUS7RjkCyuYREFk4Li+aORaEZ_Vu7Dg1nnsFuHJF+mqog@mail.gmail.com>

Hi Doug,

> > > > malloc(0) isn't undefined behaviour but implementation defined.
> > >
> > > In modern C there is no difference between those two concepts.
>
> There certainly is a difference, but in this case the practical
> implications are the same: avoid malloc(0).

Many programs wrap malloc() in some way, even if it's just to exit on
failure, so working around malloc(0) is easy enough.

    void *saneloc(size_t size) {
        void *p = malloc(size);
        if (p || size)
            return p;

        return malloc(1);
    }

> In the middle is the default signedness of chars, which generally may
> be mitigated by explicit type declarations.

Similarly, the signedness of an ‘int i: 3’ bit-field.

     (1) Whether a "plain" int bit-field is treated as a signed int
         bit-field or as an unsigned int bit-field (6.7.2, 6.7.2.1).

> Is there any other C construct that implementation-definedness renders
> useless?

There's the '-' in "%[3-7]" for fscanf(3).

    (35) The interpretation of a − character that is neither the first
         nor the last character, nor the second where a ^ character is
         the first, in the scanlist for %[ conversion in the fscanf or
         fwscanf function (7.23.6.2, 7.31.2.1).

-- 
Cheers, Ralph.

  parent reply	other threads:[~2024-09-29 21:24 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-29 16:56 Douglas McIlroy
2024-09-29 20:29 ` Rob Pike
2024-09-29 21:13   ` Rik Farrow
2024-09-29 22:21   ` Rich Salz
2024-09-29 23:56     ` Rob Pike
2024-09-30  0:36       ` Larry McVoy
2024-09-30  0:55         ` Larry McVoy
2024-09-30  1:09         ` Luther Johnson
2024-09-30  1:37           ` Luther Johnson
2024-09-30  3:52             ` ron minnich
2024-10-01 12:43             ` arnold
2024-09-30 19:12   ` Steffen Nurpmeso
2024-09-30 20:03     ` Rich Salz
2024-09-30 21:15       ` Steffen Nurpmeso
2024-09-30 22:14       ` Bakul Shah via TUHS
2024-10-01  1:42         ` Alexis
2024-09-30 20:14     ` Rik Farrow
2024-09-30 22:00       ` Steffen Nurpmeso
2024-10-01 12:53       ` Dan Cross
2024-11-18 12:00         ` Anton Shepelev
2024-11-18 12:46           ` Luther Johnson
2024-11-18 14:05             ` Steve Nickolas
2024-11-18 15:00               ` Anton Shepelev
2024-11-23 22:29                 ` Alexander Schreiber
2024-11-18 14:55             ` Anton Shepelev
2024-11-18 16:52               ` G. Branden Robinson
2024-11-18 17:00                 ` Anton Shepelev
2024-11-18 18:56                 ` Luther Johnson
2024-11-22  1:53           ` Dan Cross
2024-11-22  2:55             ` Luther Johnson
2024-09-29 21:24 ` Ralph Corderoy [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-09-28 13:34 Douglas McIlroy
2024-09-28 16:58 ` G. Branden Robinson
2024-09-28 17:47   ` Luther Johnson
2024-09-28 17:52     ` Luther Johnson
2024-09-28 18:46       ` G. Branden Robinson
2024-09-28 22:08         ` Luther Johnson
2024-09-28 22:45           ` Luther Johnson
2024-09-28 22:50             ` Luther Johnson
2024-09-28 17:59   ` Bakul Shah via TUHS
2024-09-28 22:07     ` Douglas McIlroy
2024-09-28 23:05       ` Rob Pike
2024-09-28 23:30         ` Warner Losh
2024-09-29 10:06           ` Ralph Corderoy
2024-09-29 12:25             ` Warner Losh
2024-09-29 15:17               ` Ralph Corderoy
2024-09-30 12:15           ` Dan Cross
2024-09-28 18:01   ` G. Branden Robinson
2024-10-01 13:13     ` arnold
2024-10-01 13:32       ` Larry McVoy
2024-10-01 13:47         ` arnold
2024-10-01 14:01           ` Larry McVoy
2024-10-01 14:18             ` arnold
2024-10-01 14:25             ` Luther Johnson
2024-10-01 14:56               ` Dan Cross
2024-10-01 15:08                 ` Stuff Received
2024-10-01 15:20                 ` Larry McVoy
2024-10-01 15:38                   ` Peter Weinberger (温博格) via TUHS
2024-10-01 15:50                     ` ron minnich
2024-10-01 19:04                 ` arnold
2024-10-01 16:49           ` Paul Winalski
2024-10-01 15:44       ` Bakul Shah via TUHS
2024-10-01 19:07         ` arnold
2024-10-01 20:34           ` Rik Farrow
2024-10-02  0:55             ` Steffen Nurpmeso
2024-10-02  5:49             ` arnold
2024-10-02 20:42               ` Dan Cross
2024-10-02 21:54                 ` Marc Donner
2024-10-05 17:45                 ` arnold
2024-10-06 12:20                   ` Dan Cross
2024-10-01 16:40       ` Paul Winalski
2024-09-28 18:05   ` Larry McVoy
2024-09-30 15:49     ` Paul Winalski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240929212435.6445920340@orac.inputplus.co.uk \
    --to=ralph@inputplus.co.uk \
    --cc=douglas.mcilroy@dartmouth.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).