Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

devlog.hexops.com

Post reply on HN
Print view View original

31–40 of 60 posts

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#31

Post by vlovich123 »

wffurr wrote: post #24
secondcoming wrote: post #17

I enabled ubsan on a local build of our code. It found some issues, but good god the build time was atrocious! I doubt it's something you could enable on a CI pipeline.

We run sanitizers nightly, but not as part of presubmit checks. It strikes a good balance between productivity and safety.

I’ve always run sanitized builds as presubmit without any meaningful issue. It’s always nicer to have these issues caught before code gets merged into a shared repo. The long part of things is code review anyway so waiting on a build isn’t the biggest deal in the world.

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#32

Post by bmitc »

losvedir wrote: post #2

Can anyone provide some context? I don't know what GLFW is, and the blog post doesn't really explain. From Googling, I see what it is now, but I don't really have a sense of how important GLFW bindings are. Is this very niche? Or, like is this a major contribution to game development? For that matter, is this mainly going to help Zig game developers, or is this a bit of tooling for everyone, kind of like zig cc?

This documentation has a good description of capabilities of it and alternatives.

https://www.khronos.org/opengl/wiki/Related_toolkits_and_API...

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#33

Post by kevin_thibedeau »

CUViper wrote: post #12
abainbridge wrote: post #6

The article discusses some undefined behaviour resulting from shifting an unsigned char left by 24 places. Any idea why the compiler wasn't warning about that? It seems like it would be easy to implement that warning in the compiler. I feel that I'm missing something.

It's not actually shifting a char, because integer promotion happens first. https://github.com/glfw/glfw/pull/1986#issuecomment-95578417...

Furthermore, what ubsan catches is a shift into the sign bit of that promoted char.

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#34

Post by dundarious »

abainbridge wrote: post #13
quag wrote: post #8

Earlier quoted context omitted.

That’s the point made at the end of the article. The compiler check does exist, but because it isn’t defaulted to on, no body in 6 years use it. Zig has the checks on by default, so the first time someone used it, they found and fixed it for everyone. > Anybody using GLFW could have enabled UBSan in their C compiler. Anybody could have run into this same crash and debugged it in the last 6 years. But they didn’t. Onl…

I was expecting a compile time warning and thought ubsan shouldn't be necessary. But CUViper explains why the UB can only be caught at runtime.

Integer promotion happening is known at compile time, so it’s still a fair point to expect a compile time warning.

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#35

Post by AndyKelley »

travisgriggs wrote: post #30

Seems like a cool project and kudos to the authors attentions to detail. These lines tickled my Bone of Irony: > No installing apt packages. No dealing with missing header errors. It should just work out-of-the-box, and for every platform I think it’s interesting/ironic because at some point the layers of header files were pitched as a way of making things more modular and better. A means of simplifying. Aptitude was…

There is a key difference here- if your build instructions include "install this package using apt" then you are limiting your developers to using Ubuntu or Debian, and even then limiting it to a particular version range within those distros.

If your build instructions are "zig build" then that works for everyone, on every platform: Windows, macOS, Linux (all distros!), FreeBSD, etc., and it works for all versions of them.

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#36

Post by renox »

wffurr wrote: post #24
secondcoming wrote: post #17

I enabled ubsan on a local build of our code. It found some issues, but good god the build time was atrocious! I doubt it's something you could enable on a CI pipeline.

We run sanitizers nightly, but not as part of presubmit checks. It strikes a good balance between productivity and safety.

Sure but then you waste time bisecting the commit which introduced the issue.. I wonder if the bissection couldn't be automated also in the CI.

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#37

Post by [deleted] »

dundarious wrote: post #34
abainbridge wrote: post #13

Earlier quoted context omitted.

I was expecting a compile time warning and thought ubsan shouldn't be necessary. But CUViper explains why the UB can only be caught at runtime.

Integer promotion happening is known at compile time, so it’s still a fair point to expect a compile time warning.

[deleted]

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#38

Post by justincormack »

david2ndaccount wrote: post #25

Yet another example of unnecessary undefined behavior in C as a consequence of needing to run on dead hardware. Bit shifting should clearly be defined to be operating on the underlying bits, with the resulting value being whatever that bit pattern would be on the target architecture.

“Whatever that bit pattern would be on the target architecture” is the original understanding of undefined.

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#39

Post by gpderetta »

secondcoming wrote: post #17

I enabled ubsan on a local build of our code. It found some issues, but good god the build time was atrocious! I doubt it's something you could enable on a CI pipeline.

I haven't found the sanitzer builds to be particularly slow. You mean running the test suite? Even that it wasn't particularly bad.

Re: Perfecting GLFW for Zig, and finding lurking undefined behavior that went unnot

#40

Post by flohofwoe »

A little while ago I tinkered a bit with automatically generating "more idiomatic" language bindings from C-APIs by parsing the AST-dump output of C headers from Clang (a better approach would be to use libclang I guess, but the JSON AST dump is good enough for simple C headers).

The parsed AST information is then further processed by a language-specific script which replaces some "C-isms" with target-language concepts (things like replacing pointer/size pair structs with target-language-slices). This could be further helped by custom annotations on the C-API, but so far I'm just looking for special type name patterns in the C headers. IME making C-APIs "binding friendly" even helps with making the C API a bit safer (for instance by providing a size to each data pointer).

Anyway... currently it's good enough to automatically generate Zig bindings for my Sokol libraries, but I think with a bit more work a more robust and universal tool could be created with essentially does the same thing but more flexible. Microsoft is doing something similar now to expose the Windows APIs to C++ and Rust, but as far as I have seen this is on a whole different complexity level than my handful of python scripts ;)

Here's a bit more detailed information: https://floooh.github.io/2020/08/23/sokol-bindgen.html

Post reply on HN