Is a patched in-place binary identical to the binary that would be generated from a clean compilation?
Doesn't sound like it. Seems like it appends the new versions of the functions and updates the global offset table.
Zig's New Relationship with LLVM
161–170 of 295 posts
Re: Zig's New Relationship with LLVM
#162Earlier quoted context omitted.
Ouch, my first foray into Zig several months to a year ago also ended when my compilation of a copy-pasted version of the very first Hello, World code sample failed. (Copy-pasting of the second example did work, but still) Sad to see this hasn't changed in so long. Good documentation, especially for just starting out, is crucial for language uptake.
Zig purposely does not parse carriage returns or tabs. When this is brought up, people tell you to use a separate program to format it before compiling and don't seem to acknowledge that this is not a problem with any other language. The result is that by default you get errors on windows with hello world programs. People will tell you to just change your defaults in your text editor to not write carriage returns. Th…
[deleted]
Re: Zig's New Relationship with LLVM
#163Earlier quoted context omitted.
Rust will be safer. Reasoning is pretty simple: a dynamic approach (Zig) will only catch the memory errors for the tested code paths. This is probably only marginally better than running your C++ code's test suite with address sanitizer. Rust's static approach provides memory safety for all code paths.
Your conclusion rests on the assumption that Rust's sound guarantees are free and have no cost to correctness while they might very well do, or, put differently, that "all else is equal." It's like concluding that you must be richer than me because you have more cash in your wallet. See my comment here for more: https://news.ycombinator.com/item?id=24617127
Yes, I am assuming that Rust isn't much harder to code in than Zig. Rust isn't that hard, really.
Since your point doesn't really have to do with which languages are involved (only that they are different somehow), one could similarly say that C might produce more correct programs than Rust or Zig for the same amount of effort.
New languages like Zig need to have a better story around safety than "only empirical observation will tell," because Rust's safety story is pretty compelling.
Re: Zig's New Relationship with LLVM
#164Earlier quoted context omitted.
My 0.02... and have an upvote for stating your opinion. C is not going any where.. we all know that. But it is not the best tool for accomplishing many systems programming tasks. IMO, this has probably been true since Ada95. Ada2012/SPARK, Rust, and probably Zig make this even more clear. For some domains, C was the ONLY tool available... e.g. C is/was the only language with board-level support and an available compi…
The low cost of porting a C toolchain to a new platform is a feature of C. Arguably, it's one of C's two remaining "killer apps" that keep it in use. The other is that C is the "universal recipient" language for FFI - it's easy to call C functions from almost any other language (but not vice-versa). It's currently much more expensive to port an Ada, Rust, or even C++ toolchain to a new platform, so I'd expect C to co…
The universal recipient for FFI is mostly a thing in UNIX like OSes, not so much on others.
Re: Zig's New Relationship with LLVM
#165I started messing around with zig in earnest https://github.com/agentultra/zig8 and I have to say that the development experience is great so far. The compile times are fast, the tooling is minimal in the unix sense, and it's been nice to play around with. Highlights: - compile-time evaluation - integrated testing through scoped blocks - prevents some implicit casts that we take for granted in C - catches allocation…
Compile times of the stage1 zig compiler may seem fast compared to e.g. rust or C++ but they are slow compared to what the WIP stage2 compiler can do :)
Re: Zig's New Relationship with LLVM
#166Re: Zig's New Relationship with LLVM
#167It's a very cool feature. But I wonder -- indirection via GOT sounds expensive. Could I turn it off for some critical/inner loop code?
It sounds like this is only intended for debug builds.
Re: Zig's New Relationship with LLVM
#168Earlier quoted context omitted.
Address Sanitizer and valgrind are widely-used standard tools for finding allocation bugs
They are very effective, but relatively difficult to use.
They're built into both GCC and Clang and very easy to use IMO.
The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols.
That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.
Re: Zig's New Relationship with LLVM
#169Incrementally patching binaries is obviously very cool. But is it possible that such functionality could be added to LLVM proper instead of just Zig?
i think you need to start out with support for that, adding it in hinsight is so much harder
Re: Zig's New Relationship with LLVM
#170Earlier quoted context omitted.
The low cost of porting a C toolchain to a new platform is a feature of C. Arguably, it's one of C's two remaining "killer apps" that keep it in use. The other is that C is the "universal recipient" language for FFI - it's easy to call C functions from almost any other language (but not vice-versa). It's currently much more expensive to port an Ada, Rust, or even C++ toolchain to a new platform, so I'd expect C to co…
The universal recipient for FFI is mostly a thing in UNIX like OSes, not so much on others.
Fair. So maybe C only actually has 1.5 killer features left, not 2.