Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #67424 > unrolled thread

why indentation should be part of the syntax

Back to article view | Back to comp.lang.python

Contents

  why indentation should be part of the syntax Stefan Behnel <stefan_ml@behnel.de> - 2014-03-02 11:41 +0100
    Re: why indentation should be part of the syntax Bernd Nawothnig <Bernd.Nawothnig@t-online.de> - 2014-03-02 13:07 +0100
    Re: why indentation should be part of the syntax Roy Smith <roy@panix.com> - 2014-03-02 09:38 -0500
      Re: why indentation should be part of the syntax Nicholas Cole <nicholas.cole@gmail.com> - 2014-03-02 19:08 +0000
    Re: why indentation should be part of the syntax "BartC" <bc@freeuk.com> - 2014-03-03 21:43 +0000

#67424 — why indentation should be part of the syntax

Haven't seen any mention of it on this list yet, but since it's such an
obvious flaw in quite a number of programming languages, here's a good
article on the recent security bug in iOS, which was due to accidentally
duplicated code not actually being as indented as it looked:

https://www.imperialviolet.org/2014/02/22/applebug.html

Stefan

[toc] | [next] | [standalone]

#67429

On 2014-03-02, Stefan Behnel wrote:
> Haven't seen any mention of it on this list yet, but since it's such an
> obvious flaw in quite a number of programming languages, here's a good
> article on the recent security bug in iOS, which was due to accidentally
> duplicated code not actually being as indented as it looked:
>
> https://www.imperialviolet.org/2014/02/22/applebug.html

The way Perl or Go handles it where it is not possible to omit the
curly braces would have prevented the same error too.




Bernd

-- 
no time toulouse

[toc] | [prev] | [next] | [standalone]

#67445

In article <mailman.7568.1393756930.18130.python-list@python.org>,
 Stefan Behnel <stefan_ml@behnel.de> wrote:

> Haven't seen any mention of it on this list yet, but since it's such an
> obvious flaw in quite a number of programming languages, here's a good
> article on the recent security bug in iOS, which was due to accidentally
> duplicated code not actually being as indented as it looked:
> 
> https://www.imperialviolet.org/2014/02/22/applebug.html
> 
> Stefan

Hogwash.  What this looks like is two gotos in a row.  Anybody who 
reviewed this code would have thrown up a red flag when they saw two 
gotos in a row.  If anything, the "incorrect" indentation makes it even 
more obvious.  Any static code analyzer would have also caught this as 
an unreachable statement.

Paraphrasing this into Python, you get:

def bogus():
    if SSLHashSHA1.update(hashCtx, serverRandom) != 0:
        raise fail
    if SSLHashSHA1.update(hashCtx, signedParams) != 0:
        raise fail
        raise fail
    if SSLHashSHA1.final(hashCtx, hashOut) != 0:
        raise fail

which is syntactically valid (at least, I can import it), but clearly 
not what the author intended.  So how did Python's indentation rules 
save us?

On the other hand, the Python code was actually a little annoying to 
type in because emacs refused to auto-indent the second raise!  So maybe 
the real rule is to only write code using emacs :-)

[toc] | [prev] | [next] | [standalone]

#67459

On Sun, Mar 2, 2014 at 2:38 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.7568.1393756930.18130.python-list@python.org>,
>  Stefan Behnel <stefan_ml@behnel.de> wrote:
>
>> Haven't seen any mention of it on this list yet, but since it's such an
>> obvious flaw in quite a number of programming languages, here's a good
>> article on the recent security bug in iOS, which was due to accidentally
>> duplicated code not actually being as indented as it looked:
>>
>> https://www.imperialviolet.org/2014/02/22/applebug.html
>>
>> Stefan
>
> Hogwash.  What this looks like is two gotos in a row.  Anybody who
> reviewed this code would have thrown up a red flag when they saw two
> gotos in a row.  If anything, the "incorrect" indentation makes it even
> more obvious.  Any static code analyzer would have also caught this as
> an unreachable statement.
>
> Paraphrasing this into Python, you get:
>
> def bogus():
>     if SSLHashSHA1.update(hashCtx, serverRandom) != 0:
>         raise fail
>     if SSLHashSHA1.update(hashCtx, signedParams) != 0:
>         raise fail
>         raise fail
>     if SSLHashSHA1.final(hashCtx, hashOut) != 0:
>         raise fail
>
> which is syntactically valid (at least, I can import it), but clearly
> not what the author intended.  So how did Python's indentation rules
> save us?

Actually, that's incorrect.  The bug (written in Python) would have been:

if SSLHashSHA1.update(hashCtx, signedParams) != 0:
    raise fail
raise fail # ie. no indent.

If written with the indent, it's a useless line of code, but it
doesn't become a bug.

[toc] | [prev] | [next] | [standalone]

#67589

"Stefan Behnel" <stefan_ml@behnel.de> wrote in message 
news:mailman.7568.1393756930.18130.python-list@python.org...
> Haven't seen any mention of it on this list yet, but since it's such an
> obvious flaw in quite a number of programming languages, here's a good
> article on the recent security bug in iOS, which was due to accidentally
> duplicated code not actually being as indented as it looked:
>
> https://www.imperialviolet.org/2014/02/22/applebug.html

Indentation is actually a little more fragile than block-delimited source 
code. (Press Delete inadvertently so that a tab disappears, and the code 
might still be valid, but is now wrong.)

Perhaps indentation /and/ block-delimiting would be more robust.

(And the link shows a bad example: the error should have been picked up 
anyway, but the language not only doesn't require formal indentation, but it 
uses optional block ({}) delimiters, another source of errors. Having an 
undifferentiated } to close all kinds of blocks doesn't help either.

-- 
Bartc 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web