Re: C23 thoughts and opinions

On 08/06/2024 04:55, Kaz Kylheku wrote:

On 2024-06-08, bart <bc@freeuk.com> wrote:

On 08/06/2024 01:39, Kaz Kylheku wrote:

On 2024-06-07, bart <bc@freeuk.com> wrote:

It's you who can't get your head around the idea that someone could be
away with a 'linker'.

>
You can do away with linkers and linking.
>
But it's pretty helpful when
>
1. the same library is reused for many programs.

>
You use a shared library.

 That's linking.
 Static linking is the same thing as dynamic except it's being
precomputed: the libs are dynamically processed, but then rather
than the program being run, its image is dumped into an executable.
That executable no then longer needs to repeat that library processing
when started; everything is integrated. (There are ways to optimize
linking so not all the material must be present in memory all at once
as I describe it above.)

The actual process of linking is a fairly trivial matter, as I showed in my 0.8Kloc C program which not only loads and relocates an executable file (in my format), but loads, relocates and does symbol fixups of any dynamic libraries. (Plus fixes up DLL dependencies too! But the relocation of those is done within OS routines at my request.)
What is different in formats like PE and ELF is their tremendous complexity; my formats are considerably simpler.
What I mean by 'doing anyway with linkers and linking' is removing the need to run a discrete program that might be called 'ld' or 'link' or indirectly via 'gcc', from a language implementation.
Primarily by using whole-program compilation, where any inter-module references are sorted out early on within the compiler via the global symbol table. The compiler directly generates EXE/DLL from source files.
For C, the language requires independent compilation. Here, I generate ASM files. But while traditionally those are assembled to object files and linked, I use a special assembler where ASM files are directly turned into EXE or DLL files.
The linking process is again done by manipulating a global symbol table. There are no object files, and no separate discrete link step.

2. you're selling a library, and would like to ship a binary image of
that library.

>
You ship a shared library.

 No, not always. There is such thing as selling static libraries.
 Numerical code, crypto, codecs.
 A few times in my career I worked with purchased static libs.

If you obtain a static library in the form of an object file or archive, then yes you will need a program that can process that file and combine it with the rest of your application: a linker.
But if /I/ were to write a linker, even to process PE/OFF files, it would be a 50Kloc application. (There is already such a product, not mine, which is 47KB, but it has some peculiarities.)

There are some advantages to it, like that static calls can be
faster than dynamic,

If you do your own fixups (you generate an executable where DLL dependences are resolved via your initialisation code rather than getting the OS to do it), you can arrange it so that calls to imported routines are direct.
But I don't think it's worth the trouble. You generally know that calls across FFI boundaries are going to be a tiny bit slower. That is, by needing to execute one extra indirect and probably fully predicted jump per call. So usually insignificant.
  and unused parts of static libs can be

removed at link time.
 Another aspect is that it's possible for static libs to be
platform-independent, to an extent, because some of the
object formats like COFF are widely recognized. Whereas
shared libs tend to be very OS specific. The vendor has to make
them separately for Windows, Linux, Solaris, BSD, Mac, ...

Windows tends to use PE (which includes COFF). Linux tends to use ELF.
The thing about my private formats (MX/ML) is they would have been cross-platform.

This gruntwork is a pain in the ass that is removed from
the core value of your code.
 The integrator who buys your static lib can turn it into a
shared lib for their target system, if they are so inclined.

Sure. My tools can generate OBJ files if necessary. But then it'll be somebody else who needs to invoke a linker. Not me.
But if I were to supply a binary, it would be in the form of a DLL. There are roundabout ways of bundling it into a EXE if necessary (my ML format would be better for such a purpose).