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

81–90 of 147 posts

Re: Improvements to static analysis in GCC 14

#81

Post by kolbe »

chc4 wrote: post #48
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.

"Copilot explain this error" has made this whole discussion irrelevant for me.

Re: Improvements to static analysis in GCC 14

#82

Post by jjav »

bluGill wrote: post #72
jjav wrote: post #46

Earlier quoted context omitted.

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

Wow! Longest single function I can think of having written is ~200 lines. I always feel bad when editing it but there's no useful way to break it down so I let it be. But a single 30,000 line function? Wow.

Re: Improvements to static analysis in GCC 14

#83

Post by jjav »

sirwhinesalot wrote: post #60
jjav wrote: post #44

Earlier quoted context omitted.

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

> If it were obvious it would have been done already. Witness the many variants that try to make it better but don't. Every other language with mutable strings, including C++, does it like that. It is obvious. The reason it is not done in C is not ignorance, it is laziness. > 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…

> The reason it is not done in C is not ignorance, it is laziness.

Of course not. C has been around since the dawn of UNIX and the majority of important libraries at the OS level are written in it.

Compatibility with such a vast amount of code is a lot more important than anything else.

If it were so easy why do you think nobody has done it?

> Ignoring the also obvious solution of just keeping a null terminator around

That's not very useful for the general case. If your code relies on the extra metadata (length, size) being correct and you're passing that null-terminated buffer around to libraries outside your code, it won't be correct since nothing else is aware of it.

Re: Improvements to static analysis in GCC 14

#84

Post by lynx23 »

dist1ll wrote: post #49
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.

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.

Actually, thats a reason why I never even touched Nix. Besides, being functional and all the hype, but the syntax and naming of the language feels ad-hoc enough for me to never have caught on...

Re: Improvements to static analysis in GCC 14

#85

Post by lelanthran »

sirwhinesalot wrote: post #60
jjav wrote: post #44

Earlier quoted context omitted.

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

> If it were obvious it would have been done already. Witness the many variants that try to make it better but don't. Every other language with mutable strings, including C++, does it like that. It is obvious. The reason it is not done in C is not ignorance, it is laziness. > 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…

> you should only worry about it at the boundary with the other library.

If this was a mitigation, it would solve all problems with nul-terminated strings i.e. do strict and error-checked conversions to nul-terminated strings at all boundaries to the program, and then nul-terminated strings and len-specified strings are equivalently dangerous (or safe, depending on your perspective).

The problem is precisely that unsanitised input makes its way into the application, bypassing any checks.

Re: Improvements to static analysis in GCC 14

#86

Post by lelanthran »

actionfromafar wrote: post #58
lelanthran wrote: post #31

Earlier quoted context omitted.

It's not possible to use it safely unless you know that the source string fits in the destination buffer. Every strncpy must be followed by `dst[sizeof dst - 1] = 0`, and even if you do that you still have no idea if you truncated the source string, so you have to put in a further check. strncpy (dst, src, (sizeof dst) - 1); dst[(sizeof dst) - 1] = 0; int truncated = strlen (dst) - strlen (src); Without the extra two…

if you really want to use standard C string functions, use instead: int ret = snprintf(dst, sizeof dst, "%s", src); if (ret >= n || ret or as a function: bool ya_strcpy(const char* s, char* d, size_t n) { int cp = snprintf(d, n, "%s", s); bool ok = cp >= 0 && cp

I actually do use `snprintf()` and friends.

Re: Improvements to static analysis in GCC 14

#87

Post by [deleted] »

bluGill wrote: post #71
randomdata wrote: post #32

Earlier quoted context omitted.

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.

[deleted]

Re: Improvements to static analysis in GCC 14

#88

Post by teo_zero »

Borg3 wrote: post #37
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.

#define strncpyz(d,s,l) *(strncpy(d,s,l)+(l))=0 Of course this one is unsafe for macro expansion. But well, its C :)

I'd rather put the final nul at d+l-1 than at d+l, so that l can be the size of d, not "one more than the size of d":

  strncpyz(buf,src,sizeof buf);

Re: Improvements to static analysis in GCC 14

#90

Post by kazinator »

actionfromafar wrote: post #58
lelanthran wrote: post #31

Earlier quoted context omitted.

It's not possible to use it safely unless you know that the source string fits in the destination buffer. Every strncpy must be followed by `dst[sizeof dst - 1] = 0`, and even if you do that you still have no idea if you truncated the source string, so you have to put in a further check. strncpy (dst, src, (sizeof dst) - 1); dst[(sizeof dst) - 1] = 0; int truncated = strlen (dst) - strlen (src); Without the extra two…

if you really want to use standard C string functions, use instead: int ret = snprintf(dst, sizeof dst, "%s", src); if (ret >= n || ret or as a function: bool ya_strcpy(const char* s, char* d, size_t n) { int cp = snprintf(d, n, "%s", s); bool ok = cp >= 0 && cp

snprintf only returns negative if an "encoding error" occurs, which has to do with multi-byte characters.

I think for that to possibly happen, you have to be in a locale with some character encoding in effect and snprintf is asked to print some multi-byte sequence that is invalid for that encoding.

Thus, I suspect, if you don't call that "f...f...frob my C program" function known as setlocale, it will never happen.

Post reply on HN