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

71–80 of 147 posts

Re: Improvements to static analysis in GCC 14

#71

Post by bluGill »

randomdata wrote: post #32
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…

We all agree that you shouldn't write bad code. Not using goto, not using any language construct. But when unbridled gotos were the only tool in the toolbox, bad code was an inevitability in a codebase of any meaningful size. Not even the best programmer was immune. This is what the "Go to statement considered harmful" paper was about. It was written in 1968. We listened. We created languages that addressed the conce…

In 1968 they had better languages and programmers were still using goto for control in them despite better options.

Re: Improvements to static analysis in GCC 14

#72

Post by bluGill »

jjav wrote: post #46
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…

> 30,000 line functions with gotos The problem there is the 30K line function, not the goto!

30k functions are a problem but they are manageable if goto isn't used in them. I prefer not to but a have figured them out.

Re: Improvements to static analysis in GCC 14

#73

Post by bluGill »

darby_eight wrote: post #67
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.

It does. However it catches some different things*

Re: Improvements to static analysis in GCC 14

#74

Post by GrumpySloth »

darby_eight wrote: post #68
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.

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.

Not when you called templated functions and were greeted with compile-time template stack traces. Or you called overloaded functions and were presented with 50 alternatives you might have meant. The language is inherently unfriendly to user-friendly error messages.

Re: Improvements to static analysis in GCC 14

#75

Post by darby_eight »

GrumpySloth wrote: post #74
darby_eight wrote: post #68

Earlier quoted context omitted.

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.

Not when you called templated functions and were greeted with compile-time template stack traces. Or you called overloaded functions and were presented with 50 alternatives you might have meant. The language is inherently unfriendly to user-friendly error messages.

[flagged]

Re: Improvements to static analysis in GCC 14

#76

Post by Ar-Curunir »

darby_eight wrote: post #70
hardwaregeek wrote: post #50

Earlier quoted context omitted.

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.

I have never heard C as being described to have a good type system.

Re: Improvements to static analysis in GCC 14

#77

Post by GrumpySloth »

darby_eight wrote: post #75
GrumpySloth wrote: post #74

Earlier quoted context omitted.

Not when you called templated functions and were greeted with compile-time template stack traces. Or you called overloaded functions and were presented with 50 alternatives you might have meant. The language is inherently unfriendly to user-friendly error messages.

[flagged]

I’m talking about C++. You wrote that Clang already had friendly error messages. While they were less unfriendly than GCC, calling them friendly is a stretch.

Rust having traits instead of templates is a big ergonomic improvement in that area.

Re: Improvements to static analysis in GCC 14

#78

Post by kevin_thibedeau »

i80and wrote: post #6
laweijfmvo wrote: post #4

Earlier quoted context omitted.

What's wrong with `strncpy`?

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.

strncpy() also zero pads the entire buffer. If it's significantly larger than the copied string you're wasting cycles on pointless move operations for normal, low-security string handling. This behavior is for filling in fixed length fields in data structures. It isn't suitable for general purpose string processing.

Re: Improvements to static analysis in GCC 14

#79

Post by darby_eight »

Ar-Curunir wrote: post #76
darby_eight wrote: post #70

Earlier quoted context omitted.

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

I have never heard C as being described to have a good type system.

You could try to argue this is the only source of rust's popularity.... or you could admit that the borrow checker is in fact a reason why folks use Rust over C.

Re: Improvements to static analysis in GCC 14

#80

Post by Ysraes »

sirwhinesalot wrote: post #3
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?

There's nothing wrong with simple usages of goto. The strxcpy family on the other hand is complete garbage and should never be used for any reason. I'm horrified that they're used in the kernel at all. All of those functions (and every failed attempt at "fixing" them) should have been nuked from orbit.

This is the approach taken in git https://github.com/git/git/blob/master/banned.h
Post reply on HN