Re: C23 thoughts and opinions

On 02/06/2024 04:27, Lawrence D'Oliveiro wrote:

On Sat, 1 Jun 2024 11:37:45 +0100, bart wrote:
 

My compilers don't routinely generate object files, which would also
need an external dependency (a linker), but they can do if necessary
(eg. to statically link my code into another program with another
compiler).

 Modular code design would indicate that there is no point the compiler
duplicating functionality available in the linker.

Python uses modules and yet doesn't have a linker. How on earth does it manage?
Lots of languages get by without linkers. Or without having to pointlessly write out lots of discrete files, with a lot of useful info lost, then having to read them all in again. (Look at the mess that 'objcopy' gets into.)
Quite a few compilers give the impression that they also do the job of linking:
   gcc x.c y.c z.c
produces an executable. Does it really matter here whether the 'linking' is done by a separate program on discrete files, or completely internally?
Having all modules in-memory gives you the opportunity for whole-program optimisation, will all useful info intact, without having to invent the far hairier and unwieldy concept of LTO.
Here is also my assembler in action given modules x.asm y.asm z.asm produced by my C compiler:
   aa x y z
It does the job of 'linking' but working from .asm files straight to .exe or .dll. What's the effing point of a separate linker here?
Personally I first designed out a traditional linker sometime around 1983. The special Loader I write to combined my object files into a single binary took seconds, even on floppies. A traditional linker would have taken minutes. God knows what they were doing.