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

121–130 of 147 posts

Re: Improvements to static analysis in GCC 14

#121

Post by danudey »

vintermann wrote: post #115
nh2 wrote: post #63

Earlier quoted context omitted.

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.

I could understand some kind of ancient system not having the detail or knowledge to explain what happened in particular, but this is something that still happens in a lot of Microsoft software in particular.

Outlook has a consistent tendency to give you errors like "Couldn't get your mail for some reason", or Windows saying "Hey networking isn't working". No "connection timed out" or "couldn't get an IP address" or "DNS lookup failed" or any other error message that is possible to diagnose. Even the Windows network troubleshooting wizard (the "let us try to diagnose why things aren't working for you" process) would consistently give me "yeah man idk" results, when the error is that I'm not getting an address from DHCP and should be extremely easy to diagnose.

I get that in a lot of cases, problems cut across lots of errors or areas of responsibility, and getting some other team making some other library to expose their internals to your application might be difficult in an environment like Microsoft, but it's just inexplicable that so much software, even these days, resorts to "nope can't do it" and bail out.

Re: Improvements to static analysis in GCC 14

#122

Post by jjav »

sirwhinesalot wrote: post #102
jjav wrote: post #83

Earlier quoted context omitted.

> 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 aroun…

> If it were so easy why do you think nobody has done it? People have done it, there are plenty strbuf implementations to go around. Even the kernel has seq_buf. How you handle string manipulation internally in your codebase does not matter for compatibility with existing libraries. > 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…

> People have done it, there are plenty strbuf implementations to go around.

Precisely!

Why plenty and why is none of them the standard in C?

Re: Improvements to static analysis in GCC 14

#123

Post by danudey »

snarfy wrote: post #113
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'.

In our programming class in high school we were using Borland C++; I had a classmate call me over to ask about an error they were getting from the compiler.

> "Missing semicolon on line 32"

I looked at it, looked at them, and said "You're missing a semicolon on line 32". They looked at line 32 and, hey! look at that! Forgot a semicolon at the end. Added it and their program worked fine.

Even the best error messages can't help some people.

Re: Improvements to static analysis in GCC 14

#124

Post by sirwhinesalot »

jjav wrote: post #122
sirwhinesalot wrote: post #102

Earlier quoted context omitted.

> If it were so easy why do you think nobody has done it? People have done it, there are plenty strbuf implementations to go around. Even the kernel has seq_buf. How you handle string manipulation internally in your codebase does not matter for compatibility with existing libraries. > 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…

> People have done it, there are plenty strbuf implementations to go around. Precisely! Why plenty and why is none of them the standard in C?

The TL;DR on that is basically "lazy, security unconscious assholes keep shutting it down".

Dennies Ritchie strongly suggested C should add fat pointers all the way back in 1990. Other people have pointed out the issues with zero terminated strings and arrays decaying into pointers (and the ways to deal with them even with backwards compatibility constraints) for years.

One of the most prominent was Walter Bright's article on "C's Biggest Mistake" back in 2009 and he was a C/C++ commercial compiler developer.

There is no excuse.

Re: Improvements to static analysis in GCC 14

#125

Post by arp242 »

TachyonicBytes wrote: post #118
aulin wrote: post #89

now we want a GCC language server!

You may joke, but Stallman actually tried to convince them in 2017 to modify gcc to make one out of it https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00...

Few years before that Stallman personally sabotaged this kind of tooling "because someone might abuse it". LWN did a write-up: https://lwn.net/Articles/629259/

So not surprising gcc devs weren't especially interested in on it, since Lord Stallman can come in and decree it unethical on a whim out of misguided fears.

Re: Improvements to static analysis in GCC 14

#126

Post by pwdisswordfishc »

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.

ASan seems to do quite a lot.

Re: Improvements to static analysis in GCC 14

#127

Post by tazu »

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!

I'll take a 30k line function that does one thing over 30 1k line functions that are used once...

Re: Improvements to static analysis in GCC 14

#128

Post by Eager »

A few months ago I made a neat little linux utility.

It was a drop in replacement shim for an arbitrary executable that would pretend to be the original when invoked, fork off the original and hook up to its stdout and stderr.

The error output was then fed to a custom GPT assistant that knew what program the errors came from. That assistant was tasked with turning the original errors into friendly human readable form. The output from the assistant was then sent out of the shim stderr.

It worked very well, but then I got really sick and wasn't able to work on it anymore.

I was using it for GCC / Clang errors because I had become tired of staring at heavily nested compiler dumps for concept/template issues, but you could use it for anything of course.

It would be a nice project for someone to build again, do it properly and generalize it since it doesn't look like I am going to be bouncing around again for a while.

Re: Improvements to static analysis in GCC 14

#129

Post by sirwhinesalot »

darby_eight wrote: post #69
giovannibonetti wrote: post #53

Earlier quoted context omitted.

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.

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com...

Go read the above.

Re: Improvements to static analysis in GCC 14

#130

Post by jjav »

tazu wrote: post #127
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!

I'll take a 30k line function that does one thing over 30 1k line functions that are used once...

Agreed! Breaking into multiple functions for no reason other than style isn't smart either.
Post reply on HN