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

Memory safety for web fonts

developer.chrome.com

Post reply on HN
Print view View original

51–60 of 230 posts

Re: Memory safety for web fonts

#51

Post by jasonthorsness »

cbdumas wrote: post #30
jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

Despite mounting evidence this perspective remains shockingly common. There seems to be some effect where one might convince oneself that while others are constantly introducing high severity bugs related to memory un-safety, I always follow best practices and use good tooling so I don't have that issue. Of course evidence continues to build that no tooling or coding practice eliminates the risk here. I think what's…

I sort of have this perspective, slowly changing… I think it comes from a fallacy of take a small 20-line function in C, it can be made bug-free and fully tested, a program is made of small functions, why can’t the whole thing be bug free? But somehow it doesn’t work like that in the real world.

Re: Memory safety for web fonts

#52

Post by EE84M3i »

steveklabnik wrote: post #33
gpm wrote: post #26

Earlier quoted context omitted.

I'd argue technically not due to data races on interface values, maps, slices, and strings... but close enough for almost all purposes. PS. Note that unlike most languages, a datarace on something like an int in go isn't undefined behavior, just non-deterministic and discouraged.

Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...

It's been quite a while since I worked with golang details but I seem to remember writes to the same map from multiple goroutines being UB if GOMAXPROCS>1? Did they eventually solve that, or is that excluded from the definition of memory-safe language because it's a different type of safety?

Re: Memory safety for web fonts

#53

Post by cosmic_cheese »

wkat4242 wrote: post #47
SquareWheel wrote: post #25

I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.

macOS dropped it a few years ago, primarily because there are no Macs with non-HiDPI displays any more (reducing benefit of subpixel AA) and to improve uniformity with iOS apps running on macOS via Catalyst (iOS has never supported subpixel AA, since it doesn’t play nice with frequently adjusted orientations).

Windows I believe still uses RGB subpixel AA, because OLED monitor users still need to tweak ClearType settings to make text not look bad.

Re: Memory safety for web fonts

#55

Post by whizzter »

jasonthorsness wrote: post #17

If fresh code in Rust truly reduces the number or severity of CVE in a massively tested and fuzzed C library like this one it will be a major blow to the “carefully written and tested C/C++ is just as safe” perspective. Just need the resources and Rust performance to rewrite them all.

That perspective is blown to those that see beyond themselves.

Or can admit themselves as fallible.

Or realize that even if they are near-infallible, that unless they've studied the C _and_ C++ standards to the finest detail they will probably unintentionally produce code at some point that the modern C++ compilers will manage to make vulnerable in the name of undefined behaviors optimizations (see the recent HN article about how modern C/C++ compilers has a tendency to turn fixed-time multiplications into variable time and vulnerable to timing attacks).

But of course, there is always tons of people that believe that they are better than the "average schmuck" and never produce vulnerable code.

Re: Memory safety for web fonts

#56

Post by hnuser123456 »

wkat4242 wrote: post #47
SquareWheel wrote: post #25

I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.

It absolutely still does subpixel AA. Take a screenshot of any text and zoom way in, there's red and blue fringing. And the ClearType text tuner is still a functional builtin program in Win11 24H2.

Re: Memory safety for web fonts

#57

Post by hnuser123456 »

cosmic_cheese wrote: post #53
wkat4242 wrote: post #47

Earlier quoted context omitted.

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.

macOS dropped it a few years ago, primarily because there are no Macs with non-HiDPI displays any more (reducing benefit of subpixel AA) and to improve uniformity with iOS apps running on macOS via Catalyst (iOS has never supported subpixel AA, since it doesn’t play nice with frequently adjusted orientations). Windows I believe still uses RGB subpixel AA, because OLED monitor users still need to tweak ClearType setti…

I didn't have to do any cleartype tuning on my LG C2. But maybe since it's a TV they have room for conventional subpixel layouts.

Re: Memory safety for web fonts

#58

Post by Clamchop »

wkat4242 wrote: post #47
SquareWheel wrote: post #25

I've recently been learning about how fonts render based on subpixel layouts in monitor panels. Windows assumes that all panels use RGB layout, and their ClearType software will render fonts with that assumption in mind. Unfortunately, this leads to visible text fringing on new display types, like the alternative stripe pattern used on WOLED monitors, or the triangular pattern used on QD-OLED. Some third-party tools…

I'm pretty sure windows dropped subpixel anti-aliasing a few years ago. When it did exist there was a wizard to determine and set the subpixel layout. Personally I don't bother anymore anyway since I have a HiDPI display (about 200dpi, 4K@24"). I think that's a better solution, simply have enough pixels to look smooth. It's what phones do too of course.

As far as I'm aware, ClearType is still enabled by default in Windows.

Subpixel text rendering was removed from MacOS some time ago, though, presumably because they decided it was not needed on retina screens. Maybe you're thinking of that?

Re: Memory safety for web fonts

#59

Post by TheCoreh »

Keyb0ardWarri0r wrote: post #15

This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.

> like Microsoft with its TypeScript rewrite in Go

My understanding is that Microsoft chose Go precisely to avoid having to do a full rewrite. Of all the “modern” native/AoT compiled languages (Rust, Swift, Go, Zig) Go has the most straightforward 1:1 mapping in semantics with the original TypeScript/JavaScript, so that a tool-assisted translation of the whole codebase is feasible with bug-for-bug compatibility, and minimal support/utility code.

It would be of course _possible_ to port/translate it to any language (Including Rust) but you would essentially end up implementing a small JavaScript runtime and GC, with none or very little of the safety guarantees provided by Rust. (Rust's ownership model generally favors drastically different architectures.)

Re: Memory safety for web fonts

#60

Post by cyberax »

steveklabnik wrote: post #33
gpm wrote: post #26

Earlier quoted context omitted.

I'd argue technically not due to data races on interface values, maps, slices, and strings... but close enough for almost all purposes. PS. Note that unlike most languages, a datarace on something like an int in go isn't undefined behavior, just non-deterministic and discouraged.

Yes, these issues are real, but as you say, it's not really the same as UB. As such, Go is generally considered a MSL. For anyone not familiar with this, see https://go.dev/ref/mem#restrictions Incidentally, Java is very similar: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.htm...

Java is not similar. It guarantees memory safety even for multithreaded code with data races.

It can result in stack overflows, infinite loops, but not in memory corruption.

That's not the case for Go, it's trivially easy to create memory corruption with multiple threads there.

Post reply on HN