Jump to page: 1 2
Thread overview
[OffTopic]: Safer usage of C++ in Chrome
Sep 09, 2021
Paulo Pinto
Sep 09, 2021
Basile B.
Sep 09, 2021
Kagamin
Sep 09, 2021
Paulo Pinto
Sep 09, 2021
Elronnd
Sep 09, 2021
Walter Bright
Sep 10, 2021
Adam D Ruppe
Sep 10, 2021
max haughton
Sep 10, 2021
Adam D Ruppe
Sep 10, 2021
rikki cattermole
Sep 13, 2021
Kagamin
Sep 10, 2021
Walter Bright
September 09, 2021

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

Naturally what many usually forget, is that all those development hours and bug fixes translate into salaries and contracting rates that need to be paid.

Unfortunely the marketing of how much development costs one saves by using languages like D, still don't reach most finance departments.

September 09, 2021

On Thursday, 9 September 2021 at 07:28:00 UTC, 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

Naturally what many usually forget, is that all those development hours and bug fixes translate into salaries and contracting rates that need to be paid.

Unfortunely the marketing of how much development costs one saves by using languages like D, still don't reach most finance departments.

Thanks for link. Most of the problem that are described are indeed fixed by D (minus implementation bugs, so in theory). So temporal safety is solved with escape analysis and @safe, space safety with bounds checks, UFA is solved by the GC, use of unitialized memory is solved by default initialization, etc...

Trivial question. Do I undestand correctly this sentence ?

>

Of these 2 types of safety, spatial safety is relatively easier to achieve ... (For example, you have to perform the array bounds check, which might cost more than not doing it.

without intention to offend the author, is it supposed to mean something as absurd as "checking bounds might cost more than not checking them because you have to check them" ?

September 09, 2021

Salaries are offset by the job market, no? Some people mistakenly believe that language properties matter more than the job market, but even from purely technical perspective, how do you plan to run all that web 2.0 stuff?

September 09, 2021

On 9/9/21 3: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

Naturally what many usually forget, is that all those development hours and bug fixes translate into salaries and contracting rates that need to be paid.

Unfortunely the marketing of how much development costs one saves by using languages like D, still don't reach most finance departments.

Surely, porting Chrome to D would cost more...

Where it might cost less is if you used a memory-safe-oriented language like D or Rust at the start.

-Steve

September 09, 2021

On Thursday, 9 September 2021 at 11:46:20 UTC, Steven Schveighoffer wrote:

>

On 9/9/21 3: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

Naturally what many usually forget, is that all those development hours and bug fixes translate into salaries and contracting rates that need to be paid.

Unfortunely the marketing of how much development costs one saves by using languages like D, still don't reach most finance departments.

Surely, porting Chrome to D would cost more...

Where it might cost less is if you used a memory-safe-oriented language like D or Rust at the start.

-Steve

Yes, my monetary point was about what languages get chosen when starting new projects.

This document outcome is that porting is not an option given the amount of existing code.

Even on Android, they are doing baby steps, only replacing the bluetooth stack.

However this kind of tradeoffs is why C# is finally becoming more D like in low level capabilities, since version 7.

September 09, 2021
On Thursday, 9 September 2021 at 07:28:00 UTC, 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.

99% of security bugs in browsers are due to JIT.  That's not something a language like d would help with.  There was some work done on formally verified JIT, but it's wildly complex and difficult to work with.  GC is similar—you want a GC which is attuned to JS's semantics, not just to piggyback off of D's GC, because D gc is not precise nor concurrent.
September 09, 2021
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 

"For example, Chromium already uses -fno-exceptions"

Momentum seems to be building behind the idea that exception handling is the wrong path.
September 10, 2021
On Thursday, 9 September 2021 at 23:57:43 UTC, Walter Bright wrote:
> Momentum seems to be building behind the idea that exception handling is the wrong path.

Google has always had their set of esoteric rules including this one.
September 10, 2021
On 10/09/2021 11:57 AM, Walter Bright wrote:
> Momentum seems to be building behind the idea that exception handling is the wrong path.

What I'm interested in atm is weather open-ended exceptions with stack unwinding is the wrong way to go.

Super simple question but I am starting to be of the belief that this is wrong. We need stronger compiler guarantees with compiling backed checks.

Something like this:

Basically every functions gets attributed with a __throws attribute, inferred based upon what it calls, what it catches and what it throws.

Structs only that get moved not copied, with a guarantee that it'll be caught before the thread ends and the stack will unwind due to using regular return's.

What drew me to this is my colorimetry library. I do need compiler guaranteed caught exceptional handling, but I don't want the user to wiggle out of it by using return values. The problem is exceptions need classes and the runtime handling. But I want it to work with -betterC (mixing compiler versions with shared libraries, yeah that won't end well).

With this, I *might* be able to work my way up to a full GUI toolkit. This is the big missing piece right now.

```d
struct NullPointerException {
    string message;

    string moduleName;
    int lineNumber;

    this(string message, string moduleName = __MODULE__, int lineNumber == __LINE__) {
        this.message = message;
        this.moduleName = moduleName;
        this.lineNumber = lineNumber;
    }
}

void doSomething() /* __throws() */ {
    State* state = newState;

    try {
        state.someComplexProcess();
    } catch (scope ref NullPointerException npe) {
        // ... stuff here
    }

    // scope void[NullPointerException.sizeof + size_t.sizeof] __exceptionStorage;
    // state.someComplexProcess(__exceptionStorage[]);
    // if ((cast(size_t*)&__exceptionStorage[0]) == 1 && scope ref NullPointerException npe = *(cast(NullPointerException*)&__exceptionStorage[size_t.sizeof])) {
    //      // ... stuff here
    // }
}

void someComplexProcess(State* state, /*scope void[] __exceptionStorage */) /* __throws(NullPointerException) */ {
    Process process;

    process.add(libFunc(state, /* __exceptionStorage */));
}

int libFunc(State* state, /*scope void[] __exceptionStorage */) /* __throws(NullPointerException) */ {
    if (state is null) {
        throw NullPointerException("State cannot be null");
        // if (__exceptionStorage.length < NullPointerException.sizeof + size_t.sizeof)
        //      assert(0);
        // (cast(size_t*)&__exceptionStorage[0]) = 1;
        // *(cast(NullPointerException*)&__exceptionStorage[size_t.sizeof]) = NullPointerException("State cannot be null");
        // return ReturnType.init;
    }

    return 0;
}
```
September 10, 2021
On Friday, 10 September 2021 at 00:02:36 UTC, Adam D Ruppe wrote:
> On Thursday, 9 September 2021 at 23:57:43 UTC, Walter Bright wrote:
>> Momentum seems to be building behind the idea that exception handling is the wrong path.
>
> Google has always had their set of esoteric rules including this one.

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.
« First   ‹ Prev
1 2