why indentation should be part of the syntax

[Stefan Behnel]

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

 

[Bernd Nawothnig]

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

 

[Roy Smith]

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

 

[Nicholas Cole]

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.

 

[BartC]

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.