D not considered memory safe

[Timon Gehr]

On 7/11/24 04:40, Walter Bright wrote:
> On 7/10/2024 5:19 PM, Timon Gehr wrote:
>> On 7/10/24 23:50, Walter Bright wrote:
>>> On 7/8/2024 4:18 PM, Timon Gehr wrote:
>>>> The simple fact is that if you program in a language without 
>>>> footguns, you are free to not worry about shooting your own foot. 
>>>> (Assuming you like having feet.)
>>>
>>> A "footgun" is just another word for "bug".
>>
>> This is not true. A footgun in this context is something that 
>> encourages the creation of bugs. A "footgun" is another word for 
>> "error-prone design".
> 
> 2's complement arithmetic? Floating point arithmetic? Operator precedence?
> 
> All of those are footguns.

2's complement arithmetic is indeed something people have complained 
about. I don't think `core.checkedint` is a good solution, but it should 
at least indicate that people were unsatisfied. I have complained about 
the D specification's approach to floating-point arithmetic in the past. 
Operator precedence is something that D actually innovated on in 
comparison to C in order to make it less error prone.

> We live with them because attempts to avoid 
> them make for slow and complex code.
> ...

This justification does not extend to everything that is a footgun. Some 
features are just unmitigated footguns, with essentially no upsides. 
Sometimes fixing a footgun is as simple as making syntax more explicit, 
as it is in this case.

> Back in the 70's, I read the "Pascal User Manual and Report", and 
> decided to try to write some programs in Pascal. Wirth had removed so 
> many footguns, I could not write a useful program with it. It also just 
> looked ugly. Wirth simply went too far. Subsequent implementations of 
> Pascal had to add a lot of footguns to make it a useful language.
> ...

ok.

> 
>> There is a wide spectrum between the two extremes. You are here 
>> engaging in unproductive black and white thinking.
> 
> I'm illustrating a point - that moving to "a language without footguns" 
> is not practical.

My point was not even that it is practical. :/ Please consider the 
context of my post.

Someone said that you have to choose between security and freedom, I 
said security is a form of freedom, someone doubted it. I therefore 
picked out an extreme (maybe unrealizable?) example to demonstrate that 
yes, security is indeed a form of freedom.

> In solving engineering problems, a very productive way 
> of settings up is specifying the boundary conditions. Same here.
> 
> May I say you brought it up!
> ...

No, I don't think you can. Context matters. It is you who completely 
ignored the boundary conditions of my post and went off on a tangent.

> 
>> Again, just watch your own keynote from last year's DConf. All 
>> airplanes can crash, that does not mean all cockpit designs are 
>> equivalent.
> 
> I regularly emphasize "use your best judgement",

I am.

> not blindly following 
> rules. I don't rigidly follow all the rules in my presentation, either.
> ...

I am not advocating rigidly following all rules in your presentation.

But when you of all people deviate, there should be a justification for 
it. You have so far failed to give one that is satisfactory. All you did 
was give justifications for _other_ footguns in the language, and you 
argued against footguns that are _not_ in the language, and that I am 
not even proposing. The only line of argument that would structurally 
work as a justification is your outlandish outright denial that C 
bitfields are a footgun, but this is so far removed from reality that it 
is unpersuasive as well.

> Not matching C's and C++'s struct layouts by default is a pretty big 
> footgun, and it includes the risk of memory corruption. One also would 
> be less likely to have added tests for it.
> ...

I agree. What is your point? Do you think best judgment would indicate 
that we need a footgun like that? I disagree.

If your point is actually that _I_ am in some way the one proposing 
layout mismatches, well I am not. You would be misrepresenting my point, 
utterly and absolutely.

> Use of bitfields

This is the memory safety thread, not the bitfield thread, but okay.

> for externally imposed layouts is a frankly unusual 
> case, and having one's layout not match it quite right is rather normal 
> when doing such things. One would expect testing to cover it. It also is 
> not a memory corruption problem. I.e. it's a much smaller footgun.
> ...

Differences in layout may also move pointers around, even if the 
differences originate from bitfields.

> P.S. What about extern(C) vs extern(D) functions? Is that a footgun? No, 
> because the linker will barf if your code conflates the two.

Well, what am I to say? I approve. This is sane. Why is it sane? Because 
`extern(D)` somewhat deviates from C insanity, by mangling names.

> The linker has no information on struct layouts.

This is why, clearly, `extern(C)` and `extern(D)` bitfields would need 
to have compatible layouts for code that is accepted by both.

(Anyway, arguably it could also be a good idea to put a hash of the 
struct layout in mangled names.)

> Neither does a shared library 
> interface.
> 
> Iain has complained bitterly in the past, with 100% justification, that 
> we'd change the struct layouts in the D front end and neglect to change 
> the corresponding .h files. The result was always mysterious and 
> difficult to find bugs. The end result was the tool to autogenerate 
> frontend.h and compare it for differences. Do we really want to inflict 
> that on our users by default?

No, of course we do not want to inflict that on our users by default... 
Note the structure of your argument here, which is "look at this insane 
C footgun design!". I am the one proposing more layout sanity in this 
situation. You are the one advocating for less sanity in layouts. Please 
stop trying to somehow pretend it is the other way around. It's tiresome.

> Matching the layout is a big deal.
> 

Of course!