Path: ...!news.mixmin.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: Mon, 27 May 2024 17:33:52 -0700
Organization: None to speak of
Lines: 50
Message-ID: <87cyp6zsen.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>
	<v2v59g$3cr0f$1@dont-email.me>
	<87plt8yxgn.fsf@nosuchdomain.example.com> <v31rj5$o20$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 28 May 2024 02:33:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="503aa67d7af20ebe92003f0d26656eca";
	logging-data="302719"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18glQa/NRmf/5NFDcwVkjiy"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:T7SAxb/v1SMLglSrgFqQHWTXE/Q=
	sha1:osbh17u/26Iuah4Y86nAU1t3CMM=
Bytes: 3869

David Brown <david.brown@hesbynett.no> writes:
> On 27/05/2024 01:17, Keith Thompson wrote:
[...]
>> Here's how I personally would have preferred for #embed to be
>> specified:
>> - As in current C23 drafts, #embed with no parameters must operate
>> *as
>>    if* it expanded to a comma-delimited list of integer constant
>>    expressions.
>> - With no parameters, both the common cases (initializing an array of
>>    characters) and odd cases (e.g., initializing a struct object with
>>    varying types and sizes of members) must work as specified.
>> - A standard-defined parameter allows control over optimization.
>> The parameter can be "optimize(true)" or "optimize(false)".
>> "optimize(false)" has no formal effect, but the compiler *should*
>> generate the canonical sequence of constants.
>> "optimize(true)" causes undefined behavior if #embed is used in a
>> context other than the initialization of an array of character type.
>
> I disagree here.  I want the compiler to generate the "as if" results
> regardless of any optimisation, working as currently specified.  And 
> /if/ the compiler is able to optimise the #embed, then I want it to do
> so automatically - I see no situation in which I would ever want 
> "optimize(false)".

The issue I'm trying to address (very prematurely, no doubt) is
that the decision of whether to optimize #embed vs. generating the
naive comma-separated sequence is difficult to formalize, and easy
to get wrong in corner cases.  "restrict" is another performance
hint whose only formal effect is to introduce undefined behavior
if you use it incorrectly.

Let's say I define an array of a 1-byte enumeration type, initialized
with #embed for a very large binary file.  Maybe one compiler recognizes
this as a case where it can perform the optimization, and another
doesn't.  If I can tell the compiler "trust me, I'm using this to
initialize raw byte data, and I'll take responsibility if I get it
wrong", I can see that being useful.

And maybe "optimize" isn't the best name.  Perhaps "raw_bytes"?

Without some kind of programmer control, I'm concerned that the rules
for defining an array so #embed will be correctly optimized will be
spread as lore rather than being specified anywhere.

[...]

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