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

41–50 of 147 posts

Re: Improvements to static analysis in GCC 14

#41

Post by jandrewrogers »

xedrac wrote: post #25
jandrewrogers wrote: post #14

Earlier quoted context omitted.

The use of goto is unambiguously correct and elegant in some contexts. Unwavering avoidance of goto can lead to unnecessarily ugly, convoluted code that is difficult to maintain. It usually isn't common but it has valid uses. While use of functions like `strcpy` are less advisable, there are contexts in which they are guaranteed to be correct unless other strong (e.g. language-level) invariants are broken, in which c…

> The use of goto is unambiguously correct and elegant in some contexts. For C, absolutely. For C++, it's likely a footgun.

It has fewer use cases in C++ but it still has use cases where the alternatives are worse.

Re: Improvements to static analysis in GCC 14

#43

Post by nickpsecurity »

sirwhinesalot wrote: post #38
lelanthran wrote: post #30

Earlier quoted context omitted.

> 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?

Jumping out of nested loops. Implementing higher level constructs like yield or defer. State machines. Compiler output that uses C as a "cross-platform" assembly language. All of them are better served with more specialized language constructs but as a widely applicable hammer goto is pretty nice. I don't expect C to have good error handling or generators any time soon but with goto I can deal with it.

Compiling HLL constructs in some of those scenarios ultimately produces a jump statement. So, it makes sense that a higher-level version of a jump would be helpful in the same situations.

Re: Improvements to static analysis in GCC 14

#44

Post by jjav »

sirwhinesalot wrote: post #10
i80and wrote: post #6

Earlier quoted context omitted.

strncpy won't always write a trailing nul byte, causing out of bounds reads elsewhere. It's a nasty little fellow. See the warning at https://linux.die.net/man/3/strncpy strlcpy() is better and what most people think strncpy() is, but still results in truncated strings if not used carefully which can also lead to big problems.

Speaking of strlcpy, Linus has some colorful opinions on it: > Note that we have so few 'strlcpy()' calls that we really should remove that horrid horrid interface. It's a buggy piece of sh*t. 'strlcpy()' is fundamentally unsafe BY DESIGN if you don't trust the source string - which is one of the alleged reasons to use it. --Linus Maybe strscpy is finally the one true fixed design to fix them all. Personally I think…

> the real solution is obvious

If it were obvious it would have been done already. Witness the many variants that try to make it better but don't.

> using proper string buffer types with length and capacity

Which you then can't pass to any other library. String management is very easy to solve within the boundaries of your own code. But you'll need to interact with existing code as well.

Re: Improvements to static analysis in GCC 14

#45

Post by mr_00ff00 »

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.

Re: Improvements to static analysis in GCC 14

#46

Post by jjav »

bluGill wrote: post #27
randomdata wrote: post #12

Earlier quoted context omitted.

> Last I checked they're almost as big no-nos as using goto. Huh? Why is goto a no-no? It is there for good reason. I think we all agree with Dijkstra that, in his words, unbridled gotos are harmful, but C's goto is most definitely bridled. I doubt any language created in the last 50+ years has unbridled gotos. That's an ancient programming technique that went out of fashion long ago (in large part because of Dijkstr…

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…

> 30,000 line functions with gotos

The problem there is the 30K line function, not the goto!

Re: Improvements to static analysis in GCC 14

#47

Post by someplaceguy »

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.

Clang has a similar tool, the Clang Static Analyzer: https://clang-analyzer.llvm.org/

Re: Improvements to static analysis in GCC 14

#48

Post by chc4 »

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 have had the exact opposite experience: clang constantly gives me much better error messages than GCC, implementations of some warnings or errors catch more cases, and clang-tidy is able to do much better static analysis.

Re: Improvements to static analysis in GCC 14

#49

Post by dist1ll »

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.

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.

Re: Improvements to static analysis in GCC 14

#50

Post by hardwaregeek »

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.

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.
Post reply on HN