GCC 14 Boasts Nice ASCII Art for Visualizing Buffer Overflows | Hacker News Reader

GCC 14 Boasts Nice ASCII Art for Visualizing Buffer Overflows

phoronix.com

91 pointsmfiguiere46 comments

This highlights just one of the many features, the linked site has more and is being discussed here:

https://news.ycombinator.com/item?id=39917509 - Improvements to static analysis in GCC 14 (redhat.com)

Had to check the article date at first to see if the "-Wanalyzer-infinite-loop" was a play on casually solving the halting problem with a gcc flag!

The GCC blog entry actually calls this out, which is nice.

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.

I wish I had this all those times I had to guess what buffer exploded just by looking at the Valgrind output signaling invalid reads/writes.

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.

That's not ASCII, but it does look like a nice improvement.

I actually like the use of the warning sign emoji too.

You can pass -fdiagnostics-text-art-charset=[none|ascii|unicode|emoji] if you want real ASCII.

Wait, really? That’s awesome

Thanks!

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.

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

Good point. I took a look, and it appears I hardcoded it, rather than going through our normal color management.

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)

awesome - thank you!

ASCII Art refers to the style of the art.

Similar to “8-bit” art (which may be in a 24-bit colour space)

There's color, bold and emoji.

That looks fantastic.

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.

Need the `-Wanalyzer-out-of-bounds` option and it's only static. At compile time so.

It can catch easy one, not the obscures cases.

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 was just thinking that our core tools don't have enough indecipherable punctuation.

It looks very cool, but how do screen readers parse this? My guess is not well.

How well do screen readers parse other compiler errors?

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

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.

Very cool!

Huge thanks for the effort!

An advice to anyone out there making software: give a screen reader a whirl! Take it as a learning experience!

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.

A good thing about emojis is that they'll be read correctly. Huge win for accessibility, they are.

For those curious, here's an example of emacspeak reading a fairly basic c error from the terminal: https://youtu.be/t3BgDa1p7Qc?feature=shared&t=270.

+1 for ASCII art

Reply on news.ycombinator.com