GCC's new fortification level: The gains and costs

Re:GCC's new fortification level: The gains and costs by kazinator on Monday September 19, 2022 @12:07AM (#32894182)

We had bounds checking GCC twenty five years ago.

https://stuff.mit.edu/afs/sipb/project/bounds/src/gcc-2.7.2/...

I played with that; it worked.

In the 90's I reached for Bruce Perens' Electric Fence; that did a good job for me.

We've Valgrind for some two decades now?

Call me unexcited ...

[ Parent | on HN ]

Re:GCC's new fortification level: The gains and costs by pjmlp on Monday September 19, 2022 @01:32AM (#32894613)

And we have lint since 1979.

What we miss is people actually using these tools in any meaningful way.

Instead we have to go for hardware memory tagging and sandboxing, because there is no advocacy that changes their ways.

[ Parent | on HN ]

Re:GCC's new fortification level: The gains and costs by rwmj on Monday September 19, 2022 @05:32AM (#32896142)

To be fair the overhead of bounds checking GCC was rather large. Valgrind is a better and there's no excuse for not using it in your test suite. I doubt valgrind could realistically be used in production. -D_FORTIFY_SOURCE (=2) is used in production everywhere, assuming you're running some Red Hat or SUSE derived distro.

[ Parent | on HN ]