December 08, 2022
On 12/5/2022 7:13 PM, Tejas wrote:
> People will resort have to resort to `@nogc` stuff when writing performance critical code anyways, so the protection from `D`'s GC will go away in those cases;

The myths about D's GC never seem to die.

D's GC is NEVER, EVER run unless you allocate with the GC. You don't need @nogc to disable the GC. Just don't use it. Performance critical code (well-written code) does not allocate within the critical sections anyway, so the GC will have ZERO effect on it.

December 09, 2022

On Friday, 9 December 2022 at 02:11:13 UTC, Walter Bright wrote:

>

On 12/5/2022 8:35 PM, Siarhei Siamashka wrote:

>

Many of the integer overflow bugs are caught by the C++ compiler via UBSAN during the development and never reach the end users.

While that is a good option to have on the compiler, it will only never reach the end users if there is a test case that would trigger an overflow.

https://en.wikipedia.org/wiki/Fuzzing is typically how you get these testcases in the real world. Human beta testers running debug builds with a bunch of extra runtime checks enabled may catch something too.

All of this indeed doesn't guarantee absolute 100% safety and that's the reason why we still see integer overflow security issues showing up in the stats. But without UBSAN actually existing and being actively used, the share of integer overflow issues could have been larger than 2%.

Now imagine some users in a C++ forum discussing the list of security issues in some large D application. Just like H. S. Teoh in the first message of this thread, somebody in this C++ forum could come up with the following statement: "Bounds checking is also sometimes brought up as something important; but at least according to the above categorization it only accounts for X% of issues. So not as big a deal as some may have made it sound." ;-)

December 08, 2022
On 12/8/2022 7:07 PM, Siarhei Siamashka wrote:
> Now imagine some users in a C++ forum discussing the list of security issues in some large D application. Just like H. S. Teoh in the first message of this thread, somebody in this C++ forum could come up with the following statement: *"Bounds checking is also sometimes brought up as something important; but at least according to the above categorization it only accounts for X% of issues.  So not as big a deal as some may have made it sound."* ;-)

Bounds checking is always done, so is not dependent on test coverage to find the bounds check bugs.

But I do agree that an option to insert arithmetic overflow checking would be a good thing.

What's also a good thing is an ability to mark certain calculations as "always check for overflow". You can see that in the D compiler source code in various places.
December 09, 2022
On Thursday, 8 December 2022 at 17:55:21 UTC, Walter Bright wrote:

> That's why it's a very serious problem.

There seem to be no data to support the claim that default initialization aleviates the problem of subtle bugs.
December 09, 2022
On Friday, 9 December 2022 at 06:38:36 UTC, Max Samukha wrote:
> On Thursday, 8 December 2022 at 17:55:21 UTC, Walter Bright wrote:
>
>> That's why it's a very serious problem.
>
> There seem to be no data to support the claim that default initialization aleviates the problem of subtle bugs.

*alleviates
December 09, 2022
On 12/8/2022 10:38 PM, Max Samukha wrote:
> There seem to be no data to support the claim that default initialization aleviates the problem of subtle bugs.

Plenty of personal experience resolving heisenbugs from lack of default initialization.
December 09, 2022
On 12/8/2022 10:48 PM, Max Samukha wrote:
> *alleviates

No need to worry about non-substantive typos, as nitpicking them is off topic.
December 09, 2022
On Thursday, 8 December 2022 at 23:30:56 UTC, Timon Gehr wrote:
>>> A particularly egregious case is the do-while loop:
>>>
>>> do{
>>>      int x=4;
>>>      if(condition){
>>>          ...
>>>          x++;
>>>      }
>>>      ...
>>> }while(x<10); // error
>>> ```
>>>
>>> Just... why? x)
>> 
>> Because we love to annoy people.
>> 
>
> Well, for D specifically, I hope the answer is just that the reason is that C does it this way.

Well, declaring variables within a loop is just awful style, don't do that!
And it will also not work with for-loops, but may be somewhat more obvious for humans:

for(int i = 0; i < x; ++i) // error: x undeclared
{
   int x = 10;
   ...
}


December 09, 2022
On 12/9/22 10:43, Dom DiSc wrote:
> On Thursday, 8 December 2022 at 23:30:56 UTC, Timon Gehr wrote:
>>>> A particularly egregious case is the do-while loop:
>>>>
>>>> do{
>>>>      int x=4;
>>>>      if(condition){
>>>>          ...
>>>>          x++;
>>>>      }
>>>>      ...
>>>> }while(x<10); // error
>>>> ```
>>>>
>>>> Just... why? x)
>>>
>>> Because we love to annoy people.
>>>
>>
>> Well, for D specifically, I hope the answer is just that the reason is that C does it this way.
> 
> Well, declaring variables within a loop is just awful style, don't do that!

Nonsense.

> And it will also not work with for-loops, but may be somewhat more obvious for humans:
> 
> for(int i = 0; i < x; ++i) // error: x undeclared
> {
>     int x = 10;
>     ...
> }
> 
> 

What is your point? That's a completely different case, you are accessing `x` before it is even declared.
December 09, 2022
On Friday, 9 December 2022 at 03:40:56 UTC, Walter Bright wrote:
> Bounds checking is always done

As long as you never use -release!