[OffTopic]: Safer usage of C++ in Chrome (page 2)

On 9/9/2021 12:28 AM, Paulo Pinto wrote: > Nothing new to those of us that are aware of the issues that plague C and C++ codebases in terms of security, still kind of interesting to see how much effort is being thrown at trying to fix Chrome's security exploits. > > https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76DhewaiJOhRNpjGHCxliAQTBhFxzv1QTae9o8mhBmDl32CRIuaWZLt5kVeH9e9jXv/pub This is a good summary of unsafe usage, and a guide for us in making D safer.

On Friday, 10 September 2021 at 01:03:58 UTC, max haughton wrote: > If I'm not mistaken they do allow exceptions in new code now, their famous no exception policy was mostly due to them being stuck with old design decisions. Right. There's a bad habit among people to say "well company X does this therefore it must be smart for us too", but often company X does it because of some problem specific to their codebase/organization/product which ought not be applied generally. I'd note the remainder of that document doesn't mention exceptions at all, so there's no way to evaluate the reasoning behind that one mention. It almost certainly is related to their pre-existing internal condition.

September 10, 2021

Re: [OffTopic]: Safer usage of C++ in Chrome

Posted by Steven Schveighoffer
in reply to Adam D Ruppe

Permalink

Steven Schveighoffer

Posted in reply to Adam D Ruppe

Permalink

On 9/9/21 9:24 PM, Adam D Ruppe wrote:

On Friday, 10 September 2021 at 01:03:58 UTC, max haughton wrote:

If I'm not mistaken they do allow exceptions in new code now, their famous no exception policy was mostly due to them being stuck with old design decisions.

Right.

There's a bad habit among people to say "well company X does this therefore it must be smart for us too", but often company X does it because of some problem specific to their codebase/organization/product which ought not be applied generally.

I once was in charge of maintaining code that targeted a small microprocessor. The person who first set up the build didn't know how to make the linkfile work with parameters, so it was C code, with all parameters passed via global variables (why a compiler linkfile would be able to mess this up is beyond me).

It was a long time before I figured it out, and the code base still had all the parameters as globals. But in actuality, the code the compiler generated for it was so horrendous, I kept global variables in all but the most trivial cases. It was an 8-bit CPU in a 16-bit address space, with only 8K of code ROM space, so every little bit (literally) counted. 16-bit math was to be avoided at all costs, so no pointers.

For sure, local constraints can dictate why code is written in a weird way.

-Steve

On Friday, 10 September 2021 at 00:15:17 UTC, rikki cattermole wrote: > What I'm interested in atm is weather open-ended exceptions with stack unwinding is the wrong way to go. Nobody ever said that unhandled exceptions are a way of error handling, it's a bug that terminates the program. By design exception is a mechanism that delivers error information from the error diagnostic location to the error handling location, it's not intended to fly into the sunset.

Forums