and makes this particular release of GCC (14.1) the coolest ever. indeed I have been teaching intro to C++ with similar box-like diagrams, and you know what - it takes a second for everyone in a group of 20 people to understand not only pointers, references, and buffer overruns, but also virtual tables, difference between composition and inheritance, and how the memory gets composed. visual explanations have long been a very very very weak spot in most university publications.
it is with great relief that I find ML people using lots of visual explaining rather than more weird 17th century crypto-language.
as a side-note Edward Tufte wrote a book called Visual Explanations: Images and
Quantities, Evidence and Narrative. highly recommended and inspiration for above-mentioned approach.
FWIW I implemented SARIF output in GCC 13, which gives a machine-readable interchange format for the errors. It's viewable by e.g. VS Code (via a plugin). Hopefully that makes it easier to grok the messages.
You can see an example of the output here: https://godbolt.org/z/aan6Kfxds (that's the first example from the article, with -fdiagnostics-format=sarif-stderr added to the command-line options)
That doesn't cover the diagrams though (which I currently serialize in SARIF form by making a placeholder Markdown text containing "code" containing the diagram).
I experimented with SVG output for the diagrams, but didn't get this in good enough shape for GCC 14.
I've got a few ideas for more general UX improvements with how we do diagnostics, which I'll try in GCC 15 once we're finished focusing on GCC 14 bugfixing.
They read every symbol or character that is displayed. Normal errors are verbose but at least they have meaning. Pictures that use ascii or other characters end up having all the symbols read too because there are no semantics associated with the picture.
I like to ask this question on posts about new libraries or developer tools, because most developers don't consider the accessibility of the features they're building.
This is incredible and would make for an excellent teaching tool! For students it’s generally not helpful just to crash with “invalid access.” They need to be shown where the overflow occurred and ideally what reads/writes caused it.
Nice to have though and probably saves my forehead a lot of facepalms.
Edit: I also like the lib*san way of showing the variables and where everything is and is written to when you do oob writes but that is a whole other way of getting to it.
I got a huge Premium opt-in box (on mobile) with a large button labelled "Disable" and small text to 'continue without'. I'm guessing Disable is to disable this box and subscribe to Premium so I clicked the small text not the large green Disable button.
I wonder why Phoronix enabled such levels of protection? All I can think of is that their forum is pretty toxic. But surely nobody would DDoS phoronix.com just because they were insulted for liking Wayland or, god forbid, Windows.
What would be even better is if their analysis worked. Wstringop-overflow and related features have been broken since GCC 10, for five years, and remain broken. The last time range analysis actually worked well enough to be enabled was GCC 9. Projects of realistic complexity need to run with evrp-mode=legacy, or just do what almost everyone did or wants to do: switch to clang.
Glad GCC is moving into the direction of human-readable parsing! Back in my day (like 15 years ago) any error would return a stack of unreadable template expansions.
Still, I wonder if GCC is the best tool for this visualisation. Shouldn't it be in the realm of GDB, Valgrind, or other debuggers?
Yes, a big warning during compilation is thousand times better than getting it during debugging and profiling. Because everybody must compile, but few people use GDB, and even fewer people use Valgrind.
I'd appreciate dropping red/green as bad/good colorscheme. red & green feed one of the most common visual impairments, and tend to work quite bad with terminal fg/bg colors throughout the spectrum except for its ends (black & white). Maybe you have some color profile descriptor somewhere that a user can change, but a quick search through info gcc (of my installed version) just shows the ability to turn it on & off (-fdiagnostics-color=[auto|never|always]).
Color is definitely one of the things that do NOT work well on a wide variety of terminals. try a white-on-firebrick VTE, or a black-on-darkgoldenrod (awesome for sun-glare, btw), white-on-green, white-on-purple for a change to see how well they mingle...
53 comments
[ 3.5 ms ] story [ 110 ms ] threadit is with great relief that I find ML people using lots of visual explaining rather than more weird 17th century crypto-language.
as a side-note Edward Tufte wrote a book called Visual Explanations: Images and Quantities, Evidence and Narrative. highly recommended and inspiration for above-mentioned approach.
This isn’t me trying to be snarky, I actually have no idea! Reading a C++ template error is hard enough as a sighted person
You can see an example of the output here: https://godbolt.org/z/aan6Kfxds (that's the first example from the article, with -fdiagnostics-format=sarif-stderr added to the command-line options)
That doesn't cover the diagrams though (which I currently serialize in SARIF form by making a placeholder Markdown text containing "code" containing the diagram).
I experimented with SVG output for the diagrams, but didn't get this in good enough shape for GCC 14.
I've got a few ideas for more general UX improvements with how we do diagnostics, which I'll try in GCC 15 once we're finished focusing on GCC 14 bugfixing.
An advice to anyone out there making software: give a screen reader a whirl! Take it as a learning experience!
I like to ask this question on posts about new libraries or developer tools, because most developers don't consider the accessibility of the features they're building.
It can catch easy one, not the obscures cases.
Edit: I also like the lib*san way of showing the variables and where everything is and is written to when you do oob writes but that is a whole other way of getting to it.
Negative.
https://news.ycombinator.com/item?id=39917509 - Improvements to static analysis in GCC 14 (redhat.com)
Still, I wonder if GCC is the best tool for this visualisation. Shouldn't it be in the realm of GDB, Valgrind, or other debuggers?
I actually like the use of the warning sign emoji too.
More details here: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Format...
I hope my choices here work well on a wide variety of terminals.
Color is definitely one of the things that do NOT work well on a wide variety of terminals. try a white-on-firebrick VTE, or a black-on-darkgoldenrod (awesome for sun-glare, btw), white-on-green, white-on-purple for a change to see how well they mingle...
Sorry about that. I've filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588 about this and I'll try to get it fixed before GCC 14 releases properly (i.e. for GCC 14.1)
Similar to “8-bit” art (which may be in a 24-bit colour space)