Deutsch   English   Français   Italiano  
<v4c8s4$1lki1$4@dont-email.me>

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

Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Baby X is bor nagain
Date: Wed, 12 Jun 2024 15:46:44 +0200
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <v4c8s4$1lki1$4@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> <v4c0mg$1kjmk$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 15:46:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="56b4a0ed48525cf719a93689486bb34c";
	logging-data="1757761"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX190LNnf8cvCeeuxgI8ucMW1rjBlj9y8J08="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:574CizSsiLmXsu0ALDEtmzQ6LXg=
In-Reply-To: <v4c0mg$1kjmk$1@dont-email.me>
Content-Language: en-GB
Bytes: 3918

On 12/06/2024 13:27, bart wrote:
> 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?
> 

There are some cases where lists of numbers would be useable while 
strings would not be.  But I suppose the opposite will apply too.

While string literals can contain embedded null characters (a string 
literal in C does not have to be a string), I don't feel as comfortable 
using a messy string literal full of escape codes for binary data.  A 
list of hex numbers, with appropriate line lengths, is also vastly 
neater if you need to look at the data (or accidentally open it in a 
text editor).

I also don't imagine that string literals would be much faster for 
compilation, at least for file sizes that I think make sense.  And I 
have heard (it could be wrong) that MSVC has severe limits on the size 
of string literals, though it is not a compiler I ever use myself.

But of course, if you prefer string literals, use them.  I don't think 
xxd can generate them, but it should not be hard to write a program that 
does.

> 
>>   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?
> 

10 times negligible is still negligible.

But to be clear, I'd still rate a string literal like this as vastly 
nicer than some XML monstrosity!