2 ms·

> With C you are usually delivering a compiled binary executable. If they did add a feature to C, you could use the new compiler with the new feature on your lo

> With C you are usually delivering a compiled binary executable. If they did add a feature to C, you could use the new compiler with the new feature on your local development environment. It wouldn't matter at all to the place you deployed it, as long as you make a compatible binary. You're mistaken. C has added features to its standard library before. It allows you to detect the presence of this feature at compile-time with a preprocessor definition. But if your compiler supports the feature and your target does not, in most cases you will get a fatal error regarding symbol resolution from the loader. This problem is remarkably similar to the one faced by Python developers. The difference is that Python's philosophy includes a statement regarding "batteries included", so its standard library has taken on more frequent additions than C's. In order to portably target multiple environments, you will occasionally need to handle ImportError (disable a product feature or have a fallback implementation) or (in C, e.g.) provide a fallback implementation designated as "weak". Or forego portability, capitalize on the feature, and raise the requirements for your target.

AnimalMuppet 9y ago
By "from the loader", do you mean the linker? Most of us regard that as part of compiling. Or are using .dll or .so files? For a static C program, regarding compiling and linking as part of the same (build) process, I see only two possible outcomes. Either I get an error at build time, or I get an executable that I can drop on the target that will run. The one exception I can see to this is if the program is going to make an OS call that some versions of the OS don't support.
- wyldfire 9y ago
  > By "from the loader", do you mean the linker? Most of us regard that as part of compiling. No, I meant from the dynamic loader (like ld.so). > Or are using .dll or .so files? Yes, that's a very common idiom for libc and libstdc++/libc++. Yes, you're right that statically linked binaries will not suffer this dependency and usually end up more portable (often at a cost of some memory and security/maintenance). > The one exception I can see to this is if the program is going to make an OS call that some versions of the OS don't support. Exactly. This is actually a little less rare than C library features, from what I've seen. But, here, like ImportError and providing weak impls, you can handle ENOSYS.

AnimalMuppet 9y ago

By "from the loader", do you mean the linker? Most of us regard that as part of compiling. Or are using .dll or .so files? For a static C program, regarding compiling and linking as part of the same (build) process, I see only two possible outcomes. Either I get an error at build time, or I get an executable that I can drop on the target that will run. The one exception I can see to this is if the program is going to make an OS call that some versions of the OS don't support.

wyldfire 9y ago
> By "from the loader", do you mean the linker? Most of us regard that as part of compiling. No, I meant from the dynamic loader (like ld.so). > Or are using .dll or .so files? Yes, that's a very common idiom for libc and libstdc++/libc++. Yes, you're right that statically linked binaries will not suffer this dependency and usually end up more portable (often at a cost of some memory and security/maintenance). > The one exception I can see to this is if the program is going to make an OS call that some versions of the OS don't support. Exactly. This is actually a little less rare than C library features, from what I've seen. But, here, like ImportError and providing weak impls, you can handle ENOSYS.