| |
 | Posted by Timon Gehr
in reply to Walter Bright |  Permalink Reply |
|
Timon Gehr 
Posted in reply to Walter Bright
| 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!
|
