9 ms·

What OP said has no thing to do with dynamic linking. OP is talking about the linker; the thing that generates the binary by stitching together all the compiled

by scoutt 5y ago

What OP said has no thing to do with dynamic linking. OP is talking about the linker; the thing that generates the binary by stitching together all the compiled code.

deleted 5y ago
[deleted]
imtringued 5y ago
Yes but dynamic linking causes unexpected changes at runtime of the program. Undefined behavior often happens at runtime, so an update of a library can cause undefined behavior in your application. The only way a sufficiently skilled developer can avoid undefined behavior is by checking for undefined behavior at runtime. We are now back to the reason why undefined behavior exists: because we wanted to avoid runtime checking. The idea that you can just stop writing code with undefined behavior is absurd.
- scoutt 5y ago
  > The idea that you can just stop writing code with undefined behavior is absurd. If this is true, then this should also apply to Rust or other proven languages: your program will still run in a dynamic environment, and probably calling into all kind of OS and third party libraries. Unless... you write your own (unsafe) wrappers around libraries, trying to catch, as much as possible, errors that can filter into the Rust (or whatever) code. But still, someone has to write these wrappers. If it's not you, you have to trust on somebody else's work, and this is a runtime check that will slow your program down.
  - MichaelBurge 5y ago
    Undefined behavior applies internally to the language's code, not to foreign code. FFIs specify how the compiler is to invoke foreign code, how to prepare any arguments, and how to handle any return values. They are not typically part of the language standard, but rather the OS standard. Windows has different requirements for invoking foreign code vs. Linux for example. The foreign code may have requirements on how it should be called, but it is not C's undefined behavior to invoke an OS system call incorrectly because the OS is not regulated by the C standard. You can formally prove that a program has no undefined behavior, and it can still have lots of errors when actually run.
- MichaelBurge 5y ago
  If you statically link the final binary, my point still stands: No translation unit has undefined behavior until the linker statically links them into a binary. (Actually, not until the offending code is run, but if a program can be proved to always trigger undefined behavior you can be a bit loose and say the compiled program has the undefined behavior) Dynamic linking vs. static linking is irrelevant.

by scoutt 5y ago

What OP said has no thing to do with dynamic linking. OP is talking about the linker; the thing that generates the binary by stitching together all the compiled code.

deleted 5y ago

[deleted]

imtringued 5y ago

Yes but dynamic linking causes unexpected changes at runtime of the program. Undefined behavior often happens at runtime, so an update of a library can cause undefined behavior in your application. The only way a sufficiently skilled developer can avoid undefined behavior is by checking for undefined behavior at runtime. We are now back to the reason why undefined behavior exists: because we wanted to avoid runtime checking. The idea that you can just stop writing code with undefined behavior is absurd.

scoutt 5y ago
> The idea that you can just stop writing code with undefined behavior is absurd. If this is true, then this should also apply to Rust or other proven languages: your program will still run in a dynamic environment, and probably calling into all kind of OS and third party libraries. Unless... you write your own (unsafe) wrappers around libraries, trying to catch, as much as possible, errors that can filter into the Rust (or whatever) code. But still, someone has to write these wrappers. If it's not you, you have to trust on somebody else's work, and this is a runtime check that will slow your program down.
- MichaelBurge 5y ago
  Undefined behavior applies internally to the language's code, not to foreign code. FFIs specify how the compiler is to invoke foreign code, how to prepare any arguments, and how to handle any return values. They are not typically part of the language standard, but rather the OS standard. Windows has different requirements for invoking foreign code vs. Linux for example. The foreign code may have requirements on how it should be called, but it is not C's undefined behavior to invoke an OS system call incorrectly because the OS is not regulated by the C standard. You can formally prove that a program has no undefined behavior, and it can still have lots of errors when actually run.
MichaelBurge 5y ago
If you statically link the final binary, my point still stands: No translation unit has undefined behavior until the linker statically links them into a binary. (Actually, not until the offending code is run, but if a program can be proved to always trigger undefined behavior you can be a bit loose and say the compiled program has the undefined behavior) Dynamic linking vs. static linking is irrelevant.