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

Improvements to static analysis in GCC 14

developers.redhat.com

Post reply on HN
Print view View original

61–70 of 147 posts

Re: Improvements to static analysis in GCC 14

#61

Post by estebank »

giovannibonetti wrote: post #53
mr_00ff00 wrote: post #45

Earlier quoted context omitted.

I know Rust (esp on HN) is very hyped for its memory safety and nice abstractions, but I really wonder how much Rust owes its popularity to its error messages. I would say the #1 reason I stop learning a technology is because of frustrating or unclear errors. EDIT: Getting a bit of topic, but I meant more because I love C and would love it more with rust level error messages.

Arguably Rust got good error messages by learning from Elm: https://elm-lang.org/news/compiler-errors-for-humans

Elm is acknowledged as being the initial inspiration for focusing on diagnostics early on, but Rust got good error messages through elbow grease and focused attention over a long period of time.

People getting used to good errors and demanding more, is part of the virtuous circle that keeps them high quality.

Making good looking diagnostics requires UX work, but making good diagnostics requires a flexible compiler architecture and a lot of effort, nothing more, nothing less.

Re: Improvements to static analysis in GCC 14

#62

Post by dmit »

saagarjha wrote: post #9
noam_k wrote: post #2

Very cool stuff! I haven't done much C development lately, so I'm curious how often `strcpy` and `strcat` are used. Last I checked they're almost as big no-nos as using goto. (Yes, I know goto is often preferred in kernel dev...) Can anyone share on how helpful the c-string analyses are to them?

gotos are fine if used judiciously. strcpy and strcat are “fine” in that they work when you know your code is correct and you have big problems if you don’t. But this describes most of C, unfortunately.

> gotos are fine if used judiciously

Is there a language feature that is not? :)

Re: Improvements to static analysis in GCC 14

#63

Post by nh2 »

Quekid5 wrote: post #52
dist1ll wrote: post #49

Earlier quoted context omitted.

That's what makes me wary of modifying my NixOS config. A single typo and you get an error dump comparable to C++03 templates.

... but you do get an error. That's a lot better what you typically get with C or C++. Assuming it's valid systax, of course. This is a veering off topic, but I do agree that Nix-the-language has a lot of issues. (You might suggest Guix, but I don't want to faff about with non-supported repositories for table stakes like firmware and such. Maybe Nickel will eventually provide a more pleasant and principled way to def…

My favourite Nix error message is

    infinite recursion encountered, at undefined position

Re: Improvements to static analysis in GCC 14

#64

Post by cozzyd »

lelanthran wrote: post #30
bluGill wrote: post #27

Earlier quoted context omitted.

Languages other than C give you options for flow control so that you don't need goto for that. It is a spectrum, if you only use goto to jump to the end of a small function on error it is okay, though I prefer something better in my language. I've seen 30,000 line functions with gotos used for flow control (loops and if branches) - something you can do in C if you are really that stupid and I think we will all agree…

> Languages other than C give you options for flow control so that you don't need goto for that. The idiom `if (error) goto cleanup` is about the only thing I see goto used for. What flow control replaces that other than exceptions?

RAII + destructors

Though gcc supports cleanup functions, just not very ergonomically.

Re: Improvements to static analysis in GCC 14

#65

Post by bregma »

mgaunard wrote: post #39

-Wstringop-overflow is the first warning I disable because of all the false positives. I doubt the analyze variant would fare any better.

Isn't sort of like pulling the battery out of your carbon monoxide detector because the constant beeping is giving you a headache and making you sleepy?

Re: Improvements to static analysis in GCC 14

#66

Post by Quekid5 »

nh2 wrote: post #63
Quekid5 wrote: post #52

Earlier quoted context omitted.

... but you do get an error. That's a lot better what you typically get with C or C++. Assuming it's valid systax, of course. This is a veering off topic, but I do agree that Nix-the-language has a lot of issues. (You might suggest Guix, but I don't want to faff about with non-supported repositories for table stakes like firmware and such. Maybe Nickel will eventually provide a more pleasant and principled way to def…

My favourite Nix error message is infinite recursion encountered, at undefined position

Haha, reminds me of some Scheme interpreter that would just say something like 'missing paren' at position 0 or EOF depending on where the imbalance was :)

... but, yeah... I'm pretty sure there could be some hints as to whereabouts that infinite recursion was detected.

Re: Improvements to static analysis in GCC 14

#67

Post by darby_eight »

quincepie wrote: post #42

To me fanalyzer is one of GCC killer features over clang. It makes programming C much easier by explaining errors. The error messages also began to feel similar to Rust in terms of being developer friendly.

I'm quite surprised that clang doesn't have static analysis! That doesn't seem right, but I don't program much in C anymore.

Re: Improvements to static analysis in GCC 14

#68

Post by darby_eight »

mr_00ff00 wrote: post #45
quincepie wrote: post #42

To me fanalyzer is one of GCC killer features over clang. It makes programming C much easier by explaining errors. The error messages also began to feel similar to Rust in terms of being developer friendly.

I know Rust (esp on HN) is very hyped for its memory safety and nice abstractions, but I really wonder how much Rust owes its popularity to its error messages. I would say the #1 reason I stop learning a technology is because of frustrating or unclear errors. EDIT: Getting a bit of topic, but I meant more because I love C and would love it more with rust level error messages.

Clang already had decent error messages by the time rust stabilized. There's simply not much you can do at runtime to explain a segfault.

Re: Improvements to static analysis in GCC 14

#69

Post by darby_eight »

giovannibonetti wrote: post #53
mr_00ff00 wrote: post #45

Earlier quoted context omitted.

I know Rust (esp on HN) is very hyped for its memory safety and nice abstractions, but I really wonder how much Rust owes its popularity to its error messages. I would say the #1 reason I stop learning a technology is because of frustrating or unclear errors. EDIT: Getting a bit of topic, but I meant more because I love C and would love it more with rust level error messages.

Arguably Rust got good error messages by learning from Elm: https://elm-lang.org/news/compiler-errors-for-humans

Rust's eye towards errors predates Elm entirely.

Re: Improvements to static analysis in GCC 14

#70

Post by darby_eight »

hardwaregeek wrote: post #50
mr_00ff00 wrote: post #45

Earlier quoted context omitted.

I know Rust (esp on HN) is very hyped for its memory safety and nice abstractions, but I really wonder how much Rust owes its popularity to its error messages. I would say the #1 reason I stop learning a technology is because of frustrating or unclear errors. EDIT: Getting a bit of topic, but I meant more because I love C and would love it more with rust level error messages.

Yeah Rust is popular because it's a practical language with a nice type system, decent escape hatches, and good tooling. The borrow checker attracts some, but it could have easily been done in a way with terrible usability.

> The borrow checker attracts some, but it could have easily been done in a way with terrible usability.

Why would anyone use the resulting language over C? What you're describing is C with a slightly friendlier compiler.

Post reply on HN