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

41–50 of 60 posts

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

#41

Post by abainbridge »

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.

I disagree. A simplified version of the problem expression is:

unsigned char foo = 0x80; long bar = foo It overflows and bar is set to -2147483648. If foo was initialized with 0x7f, there'd be no overflow and bar would be set to 2130706432.

In the original problem, the value of foo isn't known at compile time.

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

#42

Post by excizze »

abainbridge wrote: post #41
dundarious wrote: post #34

Earlier quoted context omitted.

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

I disagree. A simplified version of the problem expression is: unsigned char foo = 0x80; long bar = foo It overflows and bar is set to -2147483648. If foo was initialized with 0x7f, there'd be no overflow and bar would be set to 2130706432. In the original problem, the value of foo isn't known at compile time.

Probably why it's never been caught or been a problem.

Can't think of a reasonable case where a compiler would generate "bad" code because of this.

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

#43

Post by McSinyx »

AndyKelley wrote: post #35
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…

One thing that has been bugging me for quite a while is that how a Zig library would be packaged downstream. AFAICT all Zig programs have to vendor their Zig dependencies which is a huge turn-off for Debian or Fedora developers. There is not an existing way to install Zig source files and IMHO this hurts reusibility (in a different way).

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

#44

Post by abainbridge »

excizze wrote: post #42
abainbridge wrote: post #41

Earlier quoted context omitted.

I disagree. A simplified version of the problem expression is: unsigned char foo = 0x80; long bar = foo It overflows and bar is set to -2147483648. If foo was initialized with 0x7f, there'd be no overflow and bar would be set to 2130706432. In the original problem, the value of foo isn't known at compile time.

Probably why it's never been caught or been a problem. Can't think of a reasonable case where a compiler would generate "bad" code because of this.

Agreed. I think it was only a problem because of ubsan. I guess ubsan added checks to the generated code that looked at the value being shifted left 24 and saw that overflow occurred and therefore raised its undefined behaviour signal.

The code would never fail on a two's compliment machine. What ubsan is saying is that the rules of C don't guarantee this code to work - it only works because the overflow writes into the sign bit, which is where the next thing expected it to be anyway.

If the above is true, I don't think their "fix" helps: https://github.com/glfw/glfw/pull/1986/files. I would have thought that the important part is to change the longs to unsigned longs. Edit: Ah, right, that's what the discussion says: https://github.com/glfw/glfw/pull/1986

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

#45

Post by mid-kid »

McSinyx wrote: post #43
AndyKelley wrote: post #35

Earlier quoted context omitted.

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…

One thing that has been bugging me for quite a while is that how a Zig library would be packaged downstream. AFAICT all Zig programs have to vendor their Zig dependencies which is a huge turn-off for Debian or Fedora developers. There is not an existing way to install Zig source files and IMHO this hurts reusibility (in a different way).

This is an issue with any modern systems language like Go and Rust, and it doesn't seem like this trend is going to stop. NPM will happily download precompiled binaries for certain packages, and NuGet only works with prebuilt packages (like the java ecosystem).

In current day, everyone wants their own package manager, and compiled builds to have no dependencies. While this makes distribution and building easier, it makes it impossible for distro maintainers to integrate it properly into their ecosystem, apply fixes and upgrade libraries across swathes of programs. I don't get why people can't accomodate for distro packaging in their tooling as well - many languages like python handle this just fine.

I believe we'll end up at a point where the system package manager will mean nothing - it'll manage end-user programs, which will all bundle their own versions of libraries - even ones considered "system" like libc and libX11. No sharing of (security) fixes and feature upgrades, and you'll have to learn a new package manager each time you switch languages or sometimes even projects...

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

#46

Post by saagarjha »

AndyKelley wrote: post #35
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…

I mean, the build instructions could also say "install this package" and then you install it however your distribution does it.

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

#47

Post by rixed »

mid-kid wrote: post #45
McSinyx wrote: post #43

Earlier quoted context omitted.

One thing that has been bugging me for quite a while is that how a Zig library would be packaged downstream. AFAICT all Zig programs have to vendor their Zig dependencies which is a huge turn-off for Debian or Fedora developers. There is not an existing way to install Zig source files and IMHO this hurts reusibility (in a different way).

This is an issue with any modern systems language like Go and Rust, and it doesn't seem like this trend is going to stop. NPM will happily download precompiled binaries for certain packages, and NuGet only works with prebuilt packages (like the java ecosystem). In current day, everyone wants their own package manager, and compiled builds to have no dependencies. While this makes distribution and building easier, it m…

Welcome in appstore land, where the system is merely a collection of independent applications with no relationship with each other.

Makes it indeed easier to build, deploy and sell software, compared to the former world of one big distribution where thousands of software packages were designed to work together.

I do believe the driving force in this trend is not coming from the users but from the producers desire to assert property of the software. Think the enclosure trend, for software.

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

#48

Post by user-the-name »

saagarjha wrote: post #46
AndyKelley wrote: post #35

Earlier quoted context omitted.

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…

I mean, the build instructions could also say "install this package" and then you install it however your distribution does it.

Installing a package to build some code is just fundamentally wrong, though. Why am I making unspecified, permanent changes to my underlying operating system in order to build a random piece of code?

That just make no sense, and it is insane that this is the standard way of doing things.

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

#49

Post by Joker_vD »

rixed wrote: post #47
mid-kid wrote: post #45

Earlier quoted context omitted.

This is an issue with any modern systems language like Go and Rust, and it doesn't seem like this trend is going to stop. NPM will happily download precompiled binaries for certain packages, and NuGet only works with prebuilt packages (like the java ecosystem). In current day, everyone wants their own package manager, and compiled builds to have no dependencies. While this makes distribution and building easier, it m…

Welcome in appstore land, where the system is merely a collection of independent applications with no relationship with each other. Makes it indeed easier to build, deploy and sell software, compared to the former world of one big distribution where thousands of software packages were designed to work together. I do believe the driving force in this trend is not coming from the users but from the producers desire to…

> Welcome in appstore land, where the system is merely a collection of independent applications with no relationship with each other.

"App store" is having a centralized distro repository where you get all applications from (e.g. Windows Store), and "merely a collection of independent applications with no relationship with each other" is exactly the opposite (e.g. that's how the Windows apps were distributed before the advent of Windows Store).

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

#50

Post by wffurr »

renox wrote: post #36
wffurr wrote: post #24

Earlier quoted context omitted.

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.

The system we use at work does indeed bisect a build breakage automatically.
Post reply on HN