Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: Suggested method for returning a string from a C program?
Date: Tue, 25 Mar 2025 14:58:28 +0000
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <vrugaj$3ij4s$1@dont-email.me>
References: <vrd77d$3nvtf$2@dont-email.me> <vrh1br$35029$2@dont-email.me>
 <LRUCP.2$541.0@fx47.iad> <vrh71t$3be42$1@dont-email.me>
 <874izntt5t.fsf@nosuchdomain.example.com> <vrhviu$h5c$1@dont-email.me>
 <87ecyrs332.fsf@nosuchdomain.example.com> <vri9t1$a29t$1@dont-email.me>
 <20250320171505.221@kylheku.com> <vrif1v$c9ev$3@dont-email.me>
 <8734f7rw7z.fsf@nosuchdomain.example.com> <vrjjvb$1esjh$1@dont-email.me>
 <87tt7mqk7w.fsf@nosuchdomain.example.com> <vrkvt5$2k04q$2@dont-email.me>
 <87cye9afl0.fsf@nosuchdomain.example.com> <vrmckn$114k$1@dont-email.me>
 <871puoag2q.fsf@nosuchdomain.example.com> <vrnoft$15f6n$1@dont-email.me>
 <vrrh0c$qila$1@dont-email.me> <vrrouo$11up7$1@dont-email.me>
 <vrrqe0$12u8q$1@dont-email.me> <vrrs20$14vob$1@dont-email.me>
 <vrrvnh$176lu$1@dont-email.me> <vrs0j5$191gt$1@dont-email.me>
 <vrs2eu$176lu$2@dont-email.me> <vrs2r3$1b0ov$1@dont-email.me>
 <vrs7oi$1e2j7$1@dont-email.me> <vrtq62$2unrb$1@dont-email.me>
 <20250325132912.000031e4@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 25 Mar 2025 15:58:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9b3a21da3fd3fa07be1d97bdef3f85eb";
	logging-data="3755164"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18mLMwOD94LgHaJ376o7gvX"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:2ge3ZFfWdPkcKy1aK1cJ/5Vs61U=
Content-Language: en-GB
In-Reply-To: <20250325132912.000031e4@yahoo.com>
Bytes: 4992

On 25/03/2025 11:29, Michael S wrote:
> On Tue, 25 Mar 2025 08:40:34 -0000 (UTC)
> Muttley@DastardlyHQ.org wrote:
> 
>> On Mon, 24 Mar 2025 18:20:02 +0000
>> bart <bc@freeuk.com> wibbled:
>>
>>> Fast compilers and also whole-program compilers open up lots of new
>>> possibilities. But clearly you're quite happy being stuck in the
>>> stone age.
>>
>> The stone age is where they used one huge source file for a program.
>>
> 
> Separate compilation process and modularization/# of source files are
> not directly related.
> When the speed (or size, or correctness) is paramount, separate
> compilation is inevitably inferior to whole-program compilation.
> If people still use separate compilation, it does not happen because
> it is good thing, but because compilers are too slow. Or, if we're
> talking about Unix world, out of inertia.
> In Windows world release builds of majority of C/C++ software is done
> LTCG. Most developers do not even think about it, its a default. Even
> in Linux world, projects that care about experience of their users,
> like for example Firefox, use LTCG as a minimum, sometimes even going
> for profile-guided whole program compilations.

So, what exactly is released to end-users? Where is the final linking 
done? If on the user's machine, will the necessary tools also be bundled?

The way I do it is illustrated below. M/MA/C/O represent individual 
source or object files. Groups like (C, C, C) represent the multiple 
files, perhaps in assorted locations, of the original source code.

A typical C project is built like this, with -> representing compiling, 
linking etc:

  (C, C, C) -> (O, O, O) -> (EXE)

For project to be locally built (compiled, optimised and linked) at a 
user-site, then (C, C, C) must be distributed (plus the usual junk in 
addition to the compiler and linker)

My language works like this on my home machine:

  (M, M, M) -> (EXE)

But if I wanted people to build from source on their own machine (and 
assuming they had my compiler), the process would be:

  (M, M, M) -> (MA) -> (EXE)

MA is a one file source amalgamation which is what is provided. (So the 
user needs two files, that, and the compiler.)

However nobody has my compiler, as such binaries are not trusted, so the 
process is often this instead:

  (M, M, M) -> (C) -> (O) -> (EXE)

I provide the one-file C rendering. The process from that point on 
depends on their C compiler, but this is typical, even if O files are 
normally hidden, if a discrete linker is used.

So whole-program-optimisation is useful by-product.

(But it includes only the code I write; not libraries. Presumably LTCG 
works with part-compiled libraries that are to be statically linked? I 
only work with DLLs. However I don't see LTCG being practical with giant 
libraries like GTK.)

Anyway it is this intermediate single C file that is causing many people 
here to have kittens and to accuse me of not caring about modularisation.