3 ms·

No JavaScript VM is implemented in C. They are all written in a language that's a bit like C++ but has no exceptions and relies on lots of compiler behaviour th

No JavaScript VM is implemented in C. They are all written in a language that's a bit like C++ but has no exceptions and relies on lots of compiler behaviour that is not defined by the C++ standard.

woodruffw 4y ago
Hm? I can think of two pure C JS engines off the top of my head: Duktape and Elk. I believe Samsung or another vendor also has their own; they’re all somewhat common in the embedded space.
- ErikCorry 4y ago
  Fair. I'm not familiar with the tiny JS VMs. But really the main point stands: It's not possible to build a decent GC without violating strict aliasing so C and C++ as standardized are not suitable for this task.
xyzzy_plugh 4y ago
I guess this doesn't exist then: https://bellard.org/quickjs/ https://bellard.org/quickjs/
- astrange 4y ago
  This is not written in C if it doesn’t pass UBSan/ASan/Frama-C and co. It’s written in a language that just happens to look like C.
  - icedchai 4y ago
    Close enough. Will you claim the Linux kernel isn't C because it's compiled with -fno-strict-overflow and -fno-strict-aliasing ?
    - astrange 4y ago
      Yes, that’s why it only supports specific C compilers. Anything that includes its own memory allocator (that doesn’t call malloc()) is probably not implemented in standardized C.
      - icedchai 4y ago
        It’s still “C”, even if it’s a specific dialect. Vendor specific C extensions have existed forever.
  - saagarjha 4y ago
    This is incredibly pedantic, even for Hacker News. I suspect you do not wish to be responded to like this in general, so I struggle to see why it is appropriate here.
    - ErikCorry 4y ago
      The point is that if you are programming in a C dialect or a C++ dialect you will be told this again and again. Ask a question on Stackoverflow about code that requires nonstandard flags or uses UB. You will be told your program is not really in C/C++ and that your question makes no sense. You will be lectured on nasal demons for the nth time. File a bug against a compiler asking the optimizers to back off using UB to subvert the intentions of the programmer and you will be told there's no way to even know the intentions of the programmer given that the standards don't apply. So we can all move to a nomenclature where C is used loosely to indicate a family of languages, once of which happens to be standardized. I'd be happy to do that. But let's not bait and switch, using standards pedantry to dismiss feature requests and bug reports, but then turning around and saying C/C++ is suitable for implementing runtimes of other languages when nothing can really be achieved in that space without going beyond the language spec. And really in 2022 runtimes, JITs, GCs should be the primary use of C/C++. Many other uses (systems software, compilers, desktop apps, phone apps) are not suited for C/C++ due to security, stability, ease of development and newer languages that make more sense for these domains.
      - saagarjha 4y ago
        Well…the answer is that the response you get will depend. If you are familiar with the standard and how it is implemented in compilers, you will get a sense for which UBs are implicitly blessed by compilers and you can file bugs against. "I double freed a pointer and expected something reasonable to happen" is never going to get you a serious response. But if you ask something like "I tagged this pointer's bit pattern and untagged it and the pointer I got back isn't valid" you will generally be heard out. FWIW I would recommend picking a different language to write your language runtime in 2022, using it to support your new language is often a good way to invite memory unsafety bugs in your code.
    - 4y ago

No JavaScript VM is implemented in C. They are all written in a language that's a bit like C++ but has no exceptions and relies on lots of compiler behaviour that is not defined by the C++ standard.

woodruffw 4y ago

Hm? I can think of two pure C JS engines off the top of my head: Duktape and Elk. I believe Samsung or another vendor also has their own; they’re all somewhat common in the embedded space.

ErikCorry 4y ago
Fair. I'm not familiar with the tiny JS VMs. But really the main point stands: It's not possible to build a decent GC without violating strict aliasing so C and C++ as standardized are not suitable for this task.

xyzzy_plugh 4y ago

I guess this doesn't exist then: https://bellard.org/quickjs/ https://bellard.org/quickjs/

astrange 4y ago
This is not written in C if it doesn’t pass UBSan/ASan/Frama-C and co. It’s written in a language that just happens to look like C.
- icedchai 4y ago
  Close enough. Will you claim the Linux kernel isn't C because it's compiled with -fno-strict-overflow and -fno-strict-aliasing ?
  - astrange 4y ago
    Yes, that’s why it only supports specific C compilers. Anything that includes its own memory allocator (that doesn’t call malloc()) is probably not implemented in standardized C.
    - icedchai 4y ago
      It’s still “C”, even if it’s a specific dialect. Vendor specific C extensions have existed forever.
- saagarjha 4y ago
  This is incredibly pedantic, even for Hacker News. I suspect you do not wish to be responded to like this in general, so I struggle to see why it is appropriate here.
  - ErikCorry 4y ago
    The point is that if you are programming in a C dialect or a C++ dialect you will be told this again and again. Ask a question on Stackoverflow about code that requires nonstandard flags or uses UB. You will be told your program is not really in C/C++ and that your question makes no sense. You will be lectured on nasal demons for the nth time. File a bug against a compiler asking the optimizers to back off using UB to subvert the intentions of the programmer and you will be told there's no way to even know the intentions of the programmer given that the standards don't apply. So we can all move to a nomenclature where C is used loosely to indicate a family of languages, once of which happens to be standardized. I'd be happy to do that. But let's not bait and switch, using standards pedantry to dismiss feature requests and bug reports, but then turning around and saying C/C++ is suitable for implementing runtimes of other languages when nothing can really be achieved in that space without going beyond the language spec. And really in 2022 runtimes, JITs, GCs should be the primary use of C/C++. Many other uses (systems software, compilers, desktop apps, phone apps) are not suited for C/C++ due to security, stability, ease of development and newer languages that make more sense for these domains.
    - saagarjha 4y ago
      Well…the answer is that the response you get will depend. If you are familiar with the standard and how it is implemented in compilers, you will get a sense for which UBs are implicitly blessed by compilers and you can file bugs against. "I double freed a pointer and expected something reasonable to happen" is never going to get you a serious response. But if you ask something like "I tagged this pointer's bit pattern and untagged it and the pointer I got back isn't valid" you will generally be heard out. FWIW I would recommend picking a different language to write your language runtime in 2022, using it to support your new language is often a good way to invite memory unsafety bugs in your code.
  - 4y ago