The problem is not the language C, but dynamic linking. The fix is to drop dynamic linking.
But wouldn’t that be a huge loss? Isn’t dynamic linking super important because you don’t want to recompile every single program linking to a certain library when the library is updated? The thing is: It happens anyway due to versioned symbols and other things! But doesn’t static linking bloat the binary size? Just be more careful with your dependency-management and stop bloating things up! Additionally, hard-drive space and RAM are not that scarce anymore and loading times will be faster with static linking, because the system doesn’t need to look for all the referenced dynamic libraries.
And now let’s consider the other side: Static linking gives more or less true portability and absolute stability (I don’t want to update LibreSSL on my server only to find out there’s a symbol collision, and damn, it has happened to me quite a few times). Given dynamic linking has a certain significant overhead (including runtime-performance), static linking comes with savings. When using a proper non-bloated libc like musl, in comparison, you can create really small statically linked binaries. And I haven’t even started with the security benefits.
Considering this, you can see why it was a good design decision by the Golang-developers to link statically by default.
I don’t see why you need to support that use-case. If you #undef printf and printf is usually a macro, then you have pointed a gun at your foot, and it’s not libc’s job to save you.
I believe the technical term for this is “painted ourselves into a corner”.
From a human perspective, I do kind of wonder what the results would be if we said “Ok, C2025 is allowed to break backwards compatibility in minor ways when the results justify it”. A lot of arguing, I suppose. Even just removing known-broken things would be very interesting, though.
This never occurs if you statically link against libc, right? I’m pretty sure the problem here is dynamic linking having no runtime checking whatsoever (which is certainly not a bad thing in all cases)
The problem is not the language C, but dynamic linking. The fix is to drop dynamic linking.
But wouldn’t that be a huge loss? Isn’t dynamic linking super important because you don’t want to recompile every single program linking to a certain library when the library is updated? The thing is: It happens anyway due to versioned symbols and other things! But doesn’t static linking bloat the binary size? Just be more careful with your dependency-management and stop bloating things up! Additionally, hard-drive space and RAM are not that scarce anymore and loading times will be faster with static linking, because the system doesn’t need to look for all the referenced dynamic libraries.
And now let’s consider the other side: Static linking gives more or less true portability and absolute stability (I don’t want to update LibreSSL on my server only to find out there’s a symbol collision, and damn, it has happened to me quite a few times). Given dynamic linking has a certain significant overhead (including runtime-performance), static linking comes with savings. When using a proper non-bloated libc like musl, in comparison, you can create really small statically linked binaries. And I haven’t even started with the security benefits.
Considering this, you can see why it was a good design decision by the Golang-developers to link statically by default.
I don’t see why you need to support that use-case. If you
#undef printfandprintfis usually a macro, then you have pointed a gun at your foot, and it’s not libc’s job to save you.I believe the technical term for this is “painted ourselves into a corner”.
From a human perspective, I do kind of wonder what the results would be if we said “Ok, C2025 is allowed to break backwards compatibility in minor ways when the results justify it”. A lot of arguing, I suppose. Even just removing known-broken things would be very interesting, though.
This never occurs if you statically link against libc, right? I’m pretty sure the problem here is dynamic linking having no runtime checking whatsoever (which is certainly not a bad thing in all cases)