Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Tue, 28 May 2024 23:37:18 +0300
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <20240528233718.000079b9@yahoo.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>
	<87cyp6zsen.fsf@nosuchdomain.example.com>
	<v34gi3$j385$1@dont-email.me>
	<874jahznzt.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 28 May 2024 22:37:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="263fc0e2db82ed0524ddaf59936a2760";
	logging-data="786000"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/wfvQMAmk3H1ZprPaAO1Qe/DnwgET6tKI="
Cancel-Lock: sha1:51VX3+4LyHFtOmxTNh/pS6Yihvw=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 3454

On Tue, 28 May 2024 13:21:26 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> David Brown <david.brown@hesbynett.no> writes:
> > On 28/05/2024 02:33, Keith Thompson wrote:  
> [...]
> >> 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.  
> >
> > They might, but I really do not think that is so important, since
> > they will not affect the generated results.  
> 
> Right, it won't affect the generated results (assuming I use it
> correctly).  Unless I use `#embed optimize(true)` to initialize
> a struct with varying member sizes, but that's my fault because I
> asked for it.
> 
> The point is compile-timer performance, and perhaps even the ability
> to compile at all.
> 
> I'm thinking about hypothetical cases where I want to embed a
> *very* large file and parsing the comma-delimited sequence could
> have unacceptable compile-time performance, perhaps even causing
> a compile-time stack overflow depending on how the parser works.
> Every time the compiler sees #embed, it has to decide whether to
> optimize it or not, and the decision criteria are not specified
> anywhere (not at all in the standard, perhaps not clearly in the
> compiler's documentation).
> 

What about suggestion of Scott Lurndal?
Preprocessor emits implementation defined directive as a prefix to CSV
table. The directive tells to compiler to temporarily switch itself
into specialized parsing mode, probably keeping all converted numbers
in a single node in parser's results tree.
As demonstrated in several posts below, parsing by itself as well as
text to number conversion by itself, are not too bad. It's tree
management that is problematic.