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

111–120 of 147 posts

Re: Improvements to static analysis in GCC 14

#111

Post by CoastalCoder »

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.

I agree, and I'd go a step further:

In my opinion, the complexity of the interactions between C++'s {preprocessor, overload resolution, template resolution, operator overloading, and implicit casting} can make it really hard to know the meaning of a code snippet you're looking at.

If people use these features only in a very limited, disciplined manner it can be okay.

But on projects where they don't, by golly it's a mess.

(I suppose it's possible to write a horrible mess in any language, so maybe it's unfair for me to pick on C++.)

Re: Improvements to static analysis in GCC 14

#112

Post by kolbe »

estebank wrote: post #94
kolbe wrote: post #81

Earlier quoted context omitted.

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

An issue is immediacy: problems are better the earlier they are pointed out (why online errors are better than compile errorswl, which are better than CI errors, which are runtime errors). Having to copy paste an error adds a layer of indirection that gets in the way of the flow. Another is reproducibility and accuracy: LLMs have a tendency to confidently state things that are wrong, and to say different things to di…

FYI, in VS Code, you highlight the error in the terminal, right click and select "copilot explain this." One less layer of indirection. In C++, I ultimately only end up using it for 10% of the errors, but because it's the type of error with a terrible message, copilot sees through it and puts it in plain English.

I was so impressed with gpt-4's ability to diagnose and correct errors that i made this app to catch python runtime errors, and automatically make gpt-4 code inject the correction: https://github.com/matthewkolbe/OpenAIError

Re: Improvements to static analysis in GCC 14

#113

Post by snarfy »

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.

This reminds me one of the reasons I hated C++ so much. 1000+ lines of error messages about template instantiation, instead of 'error: missing semicolon'.

Re: Improvements to static analysis in GCC 14

#114

Post by xedrac »

jandrewrogers wrote: post #41
xedrac wrote: post #25

Earlier quoted context omitted.

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

What is a C++ use case where RAII doesn't solve the problem better? I imagine one exists, but I've never encountered it in 20 years. Conversely, I've seen it used inappropriately for cleanup many times (which would be fine in C).

Re: Improvements to static analysis in GCC 14

#115

Post by vintermann »

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

I tried some kind of BBC micro at a computer museum, and found out that if you had an error anywhere in your BASIC program, it would just print "error". No line number, no hint at what the problem was.

Re: Improvements to static analysis in GCC 14

#116

Post by jandrese »

jjav wrote: post #95
jandrese wrote: post #93

Earlier quoted context omitted.

For me the "real" solution looks something like this: ssize_t strxcpy(char* restrict dst, const char* restrict src, ssize_t len) Strxcpy copies the string from src to dst. The len parameter is the number of bytes available in the dst buffer. The dst buffer is always terminated with a null byte, so the maximum length of string that can be copied into it is len - 1. strxcpy returns the number of characters copied on su…

How is this useful though? I mean yes, it is useful in avoiding the buffer overruns. But that's not the only consideration, you also want code that handles data correctly. This just truncates at buffer size so data is lost. So, if you want the code to work correctly, you need to either check the return code and reallocate dst and call the copy again. But if you're going to do that might as well check src len and allo…

Sometimes truncation is fine or at least can be managed. Yes, strdup() is a better choice in a lot of situations, but depending on how your data is structured it may not be the correct option. I would say my version is useful in any situation where you were previously using strncpy/cat or strlcpy/cat.

Re: Improvements to static analysis in GCC 14

#117

Post by Peter0x44 »

someplaceguy wrote: post #47
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/

I've found it to have quite poor defaults for its analysis (things like suggesting "use annex k strcpy_s instead of strcpy"). fanalyzer is still by far the easiest to configure.

Re: Improvements to static analysis in GCC 14

#119

Post by crest »

It's hard to believe that more and more compiler writers realise that language lawyering alone isn't going to improve anything but runtime on an unchanging set of microbenchmarks. I still remember the bad old GCC 4.x error messages and those defending them explaining why they should stay like this despite a single template error easily filling ten unintelligible screen pages.

When clang was new users switched to it just for the error messages and promises not to fuck them over too hard e.g. start exploiting that signed integer overflows are "ackchyually undefined". Which is of course correct, but not what users complained about. They complained that what they considered a bugfix release broke code because the defaults changed and -fwrapv didn't even catch all the cases that used to compile to what the user needed/expected.

Re: Improvements to static analysis in GCC 14

#120

Post by crest »

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.

It's what got me pissed of enough with xmonad to discard it.
Post reply on HN