Deutsch   English   Français   Italiano  
<v30sai$3rilf$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions
Date: Mon, 27 May 2024 02:48:50 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <v30sai$3rilf$1@dont-email.me>
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>
	<v30l15$3mcj6$1@dont-email.me> <v30lls$3mepf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 27 May 2024 04:48:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1c25528c6c7e7a3bd6cadc9483b25fb8";
	logging-data="4049583"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/uq4TcgDNwUmn5wo2iPJpE"
User-Agent: Pan/0.158 (Avdiivka; )
Cancel-Lock: sha1:znO3m9hyZI7vstxkWjZgFuGDZW4=
Bytes: 3364

On Mon, 27 May 2024 01:55:24 +0100, bart wrote:

> On 27/05/2024 01:44, Lawrence D'Oliveiro wrote:
>> On Sun, 26 May 2024 13:09:36 +0200, David Brown wrote:
>> 
>>> People have always managed to embed binary source files into their
>>> binary output files - using linker tricks, or using xxd or other tools
>>> (common or specialised) to turn binary files into initialisers for
>>> constant arrays (or structs).
>> 
>> Don’t call them “tricks”. Call them “linker scripts” and “build
>> procedures”. They can do some quite complex things.
>> 
>>> #embed has two purposes.  One is to save you from using external tools
>>> for that kind of thing.
>> 
>> But it can only be a partial solution to that. It cannot replace the
>> procedures needed to construct the binary data format.
> 
> The binary data already exists, or has been created.

It might have to be created as part of the build process.

> The problem is getting it into your program as ready-to-use data rather
> than have to bundle an unwieldy collection of files in a folder
> somewhere and then have assorted routines to read them into memory.

Nothing “unwieldy” about it. It’s a bunch of temporary intermediate build 
products, generated from suitable source files like everything else in the 
build.

>> It only solves the easy part: including that binary data in the build.
> 
> Apparently that is not so easy as you seem to think.

Yes, it is as easy as I think. I’ve done this sort of thing, using 
suitable build scripts.

> Or maybe you think
> that 'embedding a file' just means adding it to a zip file?

It’s whatever “including it in the build” means. It might indeed be a zip 
component, as with resources for an Android app. Or it might be converted 
into an object file with a tool like objcopy, to be integrated into the 
executable.

> Embedding applies also to text files not just binaries.

Same principle applies.