Hacker News Reader

Comment by _benj | Hacker News Reader

I’ve been learning Zig for a few months now and what I’m in love with is the ability to just use Zig to interact with whatever C libraries I want, but doing so with the conveniences that Zig offers.

I want to use SDL2 and cairo and pango? No problem! GTK4, easy peasy! There’s a C lib that comes as a single .c file that makes it easier to interact with SDL? Drop it on the project folder and compile it with Zig along all the other .zig files!

As somebody that has been avoiding C as much as I can, I’m loving this approach since it has open the doors to the world of C for me without having to learn autotools, make, valgrind, et al

View on HN

Omg, skip the rest but valgrind is amazing and requires almost zero learning to use. Build your code with debug symbols, find inputs that trigger a segfault, then run it under valgrind. It then reports out of bounds memory access, with a full stacktrace. It's got a billion more uses, but at the most basic, that one use-case will keep you from wasting time futzing with a debugger or print-debugging 99% of segfaults and memory leaks.

Have you tried ASAN? If you like valgrind, you will be in love with ASAN, it's really surpassed it at this point IMHO.

I have tried ASAN, and I'm fully prepared to love it, but last time I tried to use it with Cython, it was pretty fidgety to configure my build system to get it running -- unlike valgrind, you need to understand how programs are compiled and linked. If you want ASAN to see into the Python that's calling/consuming your Cython, you need to build a custom Python. It's certainly a sharper tool, but valgrind has the learning curve of a hammer.

Ugh yeah, it just doesn't work well with Python. A friend of mine went down the same rabbit hole trying to debug a C extensions... it's a shame.

Yeah, I'll be honest... I know how to build Python and all that, but I stopped dead once I realized that it was a requirement. Much faster to just valgrind/[print-]debug an issue than set up all that tooling. Making all that happen is on a distant back-burner, as it will take about 10+ uses to pay off and segfaults are typically rare and shallow for me.

Be careful with ASAN on cryptographic code, though. It can introduce side channels.

ASAN is not meant to be used in production though. Or I missed something in your comment.

I've seen it advised to periodically release to production with ASAN/UBSAN/TSAN enabled, with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation. I don't have a citation to share, so take with as many grains of salt as you feel appropriate.

If nothing else, I appreciate the advisement that it can have security implications.

> with the intention that it's only 1/nth of a deployment, and even then, only deployed for enough time to collect instrumentation

You can't unleak secrets.

I agree with you, but I don't understand intent of your comment.

If you leak all the secrets 1% of the time, that's not leaking 1% of the secrets. All of the secrets have been leaked, albeit over a short stretch of time.

That's definitely a good point, and worth thinking about. But most people don't go to the trouble to rebuild dependencies like openssl. Unless you're actually implementing crypto, it seems unlikely you'd expose anything, although you do have to consider the possibility that a crypto library could call an instrumented function which could leak state.

ok, I'm down!

Using zig I finally decided to try GDB and it is amazing!

This is one of the things I really liked about working with Swift. You just got 50 years of C libraries for free, with high level features on top of it, which means there is a lot you can do.

Note that none of autotools, make, and valgrind are required for C. You could be building with meson and ninja.

Valgrind is also more useful than just for C, although admittedly it's most useful for binaries that have parts written in unchecked languages like C.

Right. Even in an entirely safe language you can have leaks, and valgrind is an effective way to find those leaks if you can afford the virtualisation overhead.

If you can't afford the virtualisation overhead, and you need to find leaks you should try what Raymond Chen suggests in "The poor man's way of identifying memory leaks" (not bothering to link since Microsoft will only move it anyway, they have several times since I read it). If you are too lazy to do it by hand, or find the technique works but wish it less manual, this is what Leakdice does:

https://github.com/tialaramex/leakdice OR https://github.com/tialaramex/leakdice-rust

http://bytepointer.com/resources/old_new_thing/20050815_224_...

(a site that tries to keep a proper backup of the ever moving writings of Chen)

As much as I dislike C from safety point or view, all of that is also easy peasy with C.

Reply on news.ycombinator.com