Path: ...!3.eu.feeder.erje.net!feeder.erje.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: relearning C: why does an in-place change to a char* segfault?
Date: Tue, 6 Aug 2024 16:57:16 +0100
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <v8th4r$1m0vg$1@dont-email.me>
References: <IoGcndcJ1Zm83zb7nZ2dnZfqnPWdnZ2d@brightview.co.uk>
 <20240801114615.906@kylheku.com> <v8gs06$2ceis$1@dont-email.me>
 <v8jlnk$31hqf$1@dont-email.me> <87bk29duba.fsf@nosuchdomain.example.com>
 <v8mkao$3n2rq$5@dont-email.me> <8734nldmea.fsf@nosuchdomain.example.com>
 <v8prni$hmng$1@dont-email.me> <871q33cw4p.fsf@nosuchdomain.example.com>
 <v8rg3j$13kvd$1@dont-email.me> <875xsebnkl.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 06 Aug 2024 17:57:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="83f58f14eb286eb7080fdcdfbfaba1b5";
	logging-data="1770480"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18oU2ni9YETm+DmOqqTMmNe"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fhJVi2O/ImDoiCHcZGk2jdUOmBc=
Content-Language: en-GB
In-Reply-To: <875xsebnkl.fsf@nosuchdomain.example.com>
Bytes: 4545

On 05/08/2024 23:40, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Sun, 04 Aug 2024 23:38:14 -0700, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> On Sat, 03 Aug 2024 19:58:37 -0700, Keith Thompson wrote:
>>>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>>>> On Sat, 03 Aug 2024 17:07:37 -0700, Keith Thompson wrote:
>>>>>>> ... general compression isn't something I've seen ...
>>>>>>
>>>>>> I recall Apple had a patent on some aspects of the “PEF” executable
>>>>>> format that they created for their PowerPC machines running old
>>>>>> MacOS. This had to do with some clever instruction encodings for
>>>>>> loading stuff into memory.
>>>>>
>>>>> Is that relevant to what I asked about?
>>>>
>>>> “Compression”
>>>
>>> Was that intended to be responsive?
>>
>> Hint: you have to know something about executable formats.
> 
> I am profoundly uninterested in hints.
> 
> Here's what you snipped from what I wrote upthread:
> 
>      What I had in mind is something that, given this:
> 
>          static int buf = { 1, 1, 1, ..., 1 }; // say, 1000 elements
> 
>      would store something less than 1000*sizeof(int) bytes in the executable
>      file.  I wouldn't be hard to do, but I'm not convinced it would be
>      worthwhile.
> 
> There's a lot I don't know about executable formats, and you seem
> uninterested in doing more than showing off your presumed knowledge
> without actually sharing it.  Others have already answered my direct
> question (Richard Damon and David Brown mentioned implementations
> that use simple run-length encoding, and David gave some reasons
> why it could be useful), so you can stop wasting everyone's time.

Storing those 1000 integers is normally going to take 4000 bytes (at 
least, since data sections may be rounded up etc).

Doing it in under 4000 bytes would require some extra help. Who or what 
is going to do that, and at what point?

There are two lots of support needed:

(1) Some process needs to run either while generating the EXE, or 
compressing an existing EXE, to convert that data into a more compact form

(2) When launched, some other process is needed to decompress the data 
before reaching the normal entry point.

I can tell you that nothing about Windows' EXE format will help here for 
either (1) or (2), since it would need support from the OS loader to 
decompress any data, and that doesn't exist.

So it would presumably need to be done by some extra code that is added 
to the executable, that needs to be arranged to run as part of the 
user-code.

A compiler that supports such compression could do this job: compressing 
sections, and then generating extra extra code, which must be called 
first, which decompresses those sections.

Or an external utility like UPX can be applied, which tyically reduces 
the size of an EXE by 2/3 (both code /and/ data), and which 
transparently expands it when launched.

So, with the existence of such a utility, I wouldn't even bother trying 
it within a compiler.