Fixing programmers

Posted Mar 18, 2019 21:46 UTC (Mon) by rweikusat2 (subscriber, #117920)
In reply to: Fixing programmers by mathstuf
Parent article: Cook: security things in Linux v5.0

As I've already explained: Intent doesn't matter. Correctness does. YMMV.

Fixing programmers

Posted Mar 18, 2019 22:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

Actually you got it wrong. Correctness doesn’t matter. The intent does.

Fixing programmers

Posted Mar 18, 2019 22:29 UTC (Mon) by rweikusat2 (subscriber, #117920) [Link] (8 responses)

If you think so, that's your opinion and not mine.

As person who spends a seriously lot of time working with other people's code (and has done so for about 15 years), I can assure you that I don't give $random_small_quantity_of_money for documentation of "programmer intent", especially not in form of otherwise uninformative comments. I need to know what the code does, not what someone believed it should be doing.

Fixing programmers

Posted Mar 18, 2019 22:33 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> I need to know what the code does, not what someone believed it should be doing.
So you need to know the intent. Duh. You're just deluding yourself at this point.

Correctness checking is TRIVIAL, it's not even worthy of mentioning. Checking of intent is anything but. And that's exactly why modern computer languages try to make it easier for developers to express their intent through code.

Fixing programmers

Posted Mar 18, 2019 22:39 UTC (Mon) by sfeam (subscriber, #2841) [Link]

I believe you have this backwards. What the code does can be determined in the absence of comments. The intent, not so much. That is why comments are valuable for bug-finding. Any place where the documented intent does not match the observed actual behavior is candidate for causing problems.

Fixing programmers

Posted Mar 19, 2019 12:24 UTC (Tue) by anselm (subscriber, #2796) [Link] (5 responses)

The goal of computer programming is to write code that does what it is supposed to be doing. You can use the code itself to figure out what it does, but you can't use the code itself to figure out whether it does what it is supposed to be doing.

It's very easy to write code that does something. Writing code that does what it it supposed to do is a lot harder, and requires outside context so you can determine when you're done. This is why in Real Life™ we have comments, specifications, unit tests, and so on – all to be able to figure out whether code does what it is supposed to do.

Fixing programmers

Posted Mar 19, 2019 14:14 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (4 responses)

There are a few fields where I can see the actual behavior of the code is of utmost importance, damn the intent. Static analysis and zero day hunting to name a few. In these cases, what the intent was actually doesn't matter and correctness is all that counts. However, these fields usually result in changes to the analyzed code when something "interesting" is found, so intent can matter again at that point.

Fixing programmers

Posted Mar 19, 2019 14:31 UTC (Tue) by NAR (subscriber, #1313) [Link] (3 responses)

what the intent was actually doesn't matter and correctness is all that counts.

How can you check correctness when you don't know what that code is supposed to do?

Fixing programmers

Posted Mar 19, 2019 14:43 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

For zero-day hacking, the intent doesn't matter. All that matters is that you can thread your special arguments through to some internal state that allows you access to something else that you normally wouldn't be able to access. In *fixing* the issue, intent again enters the picture since just closing the hole naïvely can block some use case that is supposed to be intended (or break some subtle backwards compatibility). Static analysis is similar. It's goal is to detect what the actual code does, match it against code smells and flag such code. Intent then comes in when you either suppress the notice or change the code to make the code not wrong.

Fixing programmers

Posted Mar 19, 2019 14:55 UTC (Tue) by NAR (subscriber, #1313) [Link] (1 responses)

that allows you access to something else that you normally wouldn't be able to access.

You're making the assumption that this particular access was not intended. So intent matters.

Fixing programmers

Posted Mar 19, 2019 14:59 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Granted, but I feel that the intent that matters is a much higher-level construct in black hat hacking than "should this case statement have a break statement?".

Fixing programmers

Posted Mar 19, 2019 10:02 UTC (Tue) by NAR (subscriber, #1313) [Link] (3 responses)

Intent doesn't matter. Correctness does.

Let's say I have this code snippet: a = b + c; Is it correct?

Fixing programmers

Posted Mar 19, 2019 21:44 UTC (Tue) by neilbrown (subscriber, #359) [Link] (2 responses)

> Let's say I have this code snippet: a = b + c; Is it correct?

Yes it is.
Your statement "I have this code snippet: a = b + c" is self-evidently correct.

Fixing programmers

Posted Mar 19, 2019 22:03 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

By that definition, the Therac-25 "correctly" killed three people.

Fixing programmers

Posted Mar 19, 2019 23:24 UTC (Tue) by neilbrown (subscriber, #359) [Link]

> By that definition, the Therac-25 "correctly" killed three people.

Sorry to correct you, but I think you mean "It is correct that 'The Therac-25 killed three people' ".

And this is the point - when people start using broad terms like "intent" and "correct" without ensuring that all corespondents are using them in the same sense, you can hardly expect a useful conversation to result.

(wouldn't it be great if people would think about what they write, instead of just writing about what they think).