Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Wed, 12 Jun 2024 12:27:13 +0100
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <v4c0mg$1kjmk$1@dont-email.me>
References: <v494f9$von8$1@dont-email.me>
 <v49seg$14cva$1@raubtier-asyl.eternal-september.org>
 <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 12 Jun 2024 13:27:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8931784699f912088de057f0fe47679d";
	logging-data="1724116"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1919eSmyiO8WEfpl4VHt0nB"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:8civsWko86jnJISPOUbJqHr+MTE=
In-Reply-To: <v4bh56$1hibd$1@dont-email.me>
Content-Language: en-GB
Bytes: 2602

On 12/06/2024 08:01, David Brown wrote:
> On 12/06/2024 07:40, Bonita Montero wrote:

>> I converted my code into sth. that produces a C-string as an output.
>> Printing that is still very fast, i.e. the files produced are written
>> with about 2.6GiB/s. But the problem is still that all compilers don't
>> parse large files but quit with an out of memory error. So having a
>> .obj output along with a small header file would be the best.
>>
> 
> How big files are you talking about?  In an earlier thread (which I 
> thought had beaten this topic to death), "xxd -i" include files were 
> fine to at least a few tens of megabytes with gcc.

What was never discussed is why xxd  (and the faster alternates that 
some posted to do that task more quickly), produces lists of numbers anyway.

Why not strings containing the embedded binary data?


>  And it would be, 
> IMHO, absurd to have much bigger files than that embedded with your 
> executable in this manner.


BM complained that some files expressed as xxd-like output were causing 
problems with compilers.

I suggested using a string representation. While the generated text file 
is not much smaller, it is seen by the compiler as one string 
expression, instead of millions of small expressions. Or at least, 
1/20th the number if you split the strings across lines.

It's a no-brainer. Why spend 10 times as long on processing such data?