3 ms·

A language that compiles to C does not inherit all of C's problems, and doesn't "punt" on it for undefined behavior. I mean, after all, Rust compiles to Assembl

by lmkg 6y ago

A language that compiles to C does not inherit all of C's problems, and doesn't "punt" on it for undefined behavior. I mean, after all, Rust compiles to Assembly, which is even unsafer than C, but Rust is still considered safe. A compiler has greater ability to enforce invariants that make the resulting code safe. The issues with C result from faulty humans; running through a program gives an opportunity for those issues never to occur to begin with.

umanwizard 6y ago
How is assembly less safe than C? C is full of undefined behavior which might be interpreted differently by different compilers, whereas (maybe with the exception of some unusual circumstances) the behavior of assembly language for major instruction sets is 100% documented.
- ncmncm 6y ago
  I see that you have not coded in assembly language.
  - umanwizard 6y ago
    I haven’t; I’ve only read it a bit. I could be wrong about a relative lack of UB compared to C - do you have examples?
    - ncmncm 6y ago
      When you code in assembly language, you discover how incompletely documented every chip is. Any detail of behavior not documented might change in a later chip, and is thus UB. Makers of compatible chips are obliged to keep a collection of systems with all the extant chip designs to run experiments against, and to maintain their own documentation of discovered but unspecified commonalities that users' code may have come to depend on. Each released chip, and each stepping of each release, has its own unique set of bugs-- deviations from documentation, from observed behavior of previous chips, and of chips yet to be released. Writers of assembly code need a compendium of behaviors, documented or not, that cannot be relied on for the set of release platforms. Many such bugs depend on an ill-characterized history of processor states, making them, often, (more or less) reliably reproducible only with a particular program that was discovered to evoke each. Often the behavior noted is seen only once in a million runs. An example on Intel is the popcount instruction that runs very slowly, sometimes, in chips released up to a few years ago. The instruction appeared along with ...SSE3?, and had the bug until it was noticed and fixed in a subsequent chip. The bug is the reason Gcc uses the same register for source and destination when it emits this instruction. Intel's ISA manual does not mention this behavior.
      - umanwizard 6y ago
        Thank you for the details. I guess I had an overly rose-tinted view of the quality of Intel documentation.
vmchale 6y ago
> A language that compiles to C does not inherit all of C's problems, and doesn't "punt" on it for undefined behavior. ATS avoids some things; you shouldn't be able to do the silly memory-unsafe parts. Stuff like dividing by zero is permissible by default but can be avoided.

by lmkg 6y ago

umanwizard 6y ago

How is assembly less safe than C? C is full of undefined behavior which might be interpreted differently by different compilers, whereas (maybe with the exception of some unusual circumstances) the behavior of assembly language for major instruction sets is 100% documented.

ncmncm 6y ago
I see that you have not coded in assembly language.
- umanwizard 6y ago
  I haven’t; I’ve only read it a bit. I could be wrong about a relative lack of UB compared to C - do you have examples?
  - ncmncm 6y ago
    When you code in assembly language, you discover how incompletely documented every chip is. Any detail of behavior not documented might change in a later chip, and is thus UB. Makers of compatible chips are obliged to keep a collection of systems with all the extant chip designs to run experiments against, and to maintain their own documentation of discovered but unspecified commonalities that users' code may have come to depend on. Each released chip, and each stepping of each release, has its own unique set of bugs-- deviations from documentation, from observed behavior of previous chips, and of chips yet to be released. Writers of assembly code need a compendium of behaviors, documented or not, that cannot be relied on for the set of release platforms. Many such bugs depend on an ill-characterized history of processor states, making them, often, (more or less) reliably reproducible only with a particular program that was discovered to evoke each. Often the behavior noted is seen only once in a million runs. An example on Intel is the popcount instruction that runs very slowly, sometimes, in chips released up to a few years ago. The instruction appeared along with ...SSE3?, and had the bug until it was noticed and fixed in a subsequent chip. The bug is the reason Gcc uses the same register for source and destination when it emits this instruction. Intel's ISA manual does not mention this behavior.
    - umanwizard 6y ago
      Thank you for the details. I guess I had an overly rose-tinted view of the quality of Intel documentation.

vmchale 6y ago

> A language that compiles to C does not inherit all of C's problems, and doesn't "punt" on it for undefined behavior. ATS avoids some things; you shouldn't be able to do the silly memory-unsafe parts. Stuff like dividing by zero is permissible by default but can be avoided.