Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Tue, 28 May 2024 13:54:31 -0700
Organization: None to speak of
Lines: 49
Message-ID: <87sey1y7w8.fsf@nosuchdomain.example.com>
References: <v2l828$18v7f$1@dont-email.me>
	<00297443-2fee-48d4-81a0-9ff6ae6481e4@gmail.com>
	<v2lji1$1bbcp$1@dont-email.me>
	<87msoh5uh6.fsf@nosuchdomain.example.com>
	<f08d2c9f-5c2e-495d-b0bd-3f71bd301432@gmail.com>
	<v2nbp4$1o9h6$1@dont-email.me> <v2ng4n$1p3o2$1@dont-email.me>
	<87y18047jk.fsf@nosuchdomain.example.com>
	<87msoe1xxo.fsf@nosuchdomain.example.com>
	<v2sh19$2rle2$2@dont-email.me>
	<87ikz11osy.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 28 May 2024 22:54:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="503aa67d7af20ebe92003f0d26656eca";
	logging-data="811827"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18NFdMg5+A8fJZCqYL4s3jc"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:GqKhyg/aNrwEWiv6lTSGjWsF8zU=
	sha1:JCHqgp6ZuypI0FjgfHEM/a+eSww=
Bytes: 3590

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> The *embed element width* is typically going to be CHAR_BIT bits by
> default.  It can only be changed by an *implementation-defined* embed
> parameter.  It seems odd that there's no standard way to specify the
> element width.
>
> It seems even more odd that the embed element width is
> implementation defined and not set to CHAR_BIT by default.
> A conforming implementation could set the embed element width to,
> say, 4*CHAR_BIT and then not provide an implementation-defined embed
> parameter to specify a different width, making #embed unusable for
> unsigned char arrays.  (N3220 is a draft, not the final C23 standard,
> but I haven't heard about any changes in this area.)
[...]

I was wrong about this.  The default embed element width is CHAR_BIT.
It can be changed by an implementation-defined embed parameter;
implementations aren't required to support such a parameter.

The term "embed element width" is defined in N3220 6.10.4.1p6, under
Constraints:

    Let *embed element width* be either:
        - an integer constant expression greater than zero determined by
          an implementation-defined embed parameter; or,
        — CHAR_BIT (5.2.5.3.2).
    The result of (*resource width*) % (*embed element width*) shall be
    zero.

with a footnote:

    This constraint helps ensure data is neither filled with padding
    values nor truncated in a given environment, and helps ensure the
    data is portable with respect to usages of memcpy (7.26.2.1) with
    character type arrays initialized from the data.

And of course CHAR_BIT is the byte size on the target (relevant for
cross-compilers).  In the odd case where CHAR_BIT is different on the
host and target systems, the embedded file needs to be one that could be
used on the target (if the target supports files).

It's probably reasonable for an implementation to support *only*
CHAR_BIT as the embed element width, and not to provide a mechanism to
change it.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */