Re: relearning C: why does an in-place change to a char* segfault?

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.