Hacker News Reader

Comment by realusername | Hacker News Reader

I feel most of these vulnerabilities should not exist in the first place. When you create a language that's specifically made to handle money that also is immutable (so without possibility to rollback), it should be generally a bit more secure than the average language.

The VM should be protected against integer overflows and functions should be protected by default, I don't really get those design choices.

View on HN

Oh it’s even worse than overflows. The order of operations of Solidity isn’t even the same as most languages, which will undoubtedly lead to issues at some point. https://twitter.com/esultanik/status/976186942625861632

What a bad language design... I thought they mostly copied javascript but not even that one works in javascript so who knows what they thought when designing the operators.

I fail to see the problem in that code.

    (1 | 0 < 1)

evaluates to False in python as well.

There's a, what, 50 year tradition in C of boolean ORs evaluating left to right. I don't know truthiness rules in Python, but the REPL just told me 1 is not False. So we have something that is not False ORed with True. What is your thought process?

The issue here is operator precedence.

Is it evaluated liked (1 | (0 < 1)) or like ((1 | 0) < 1).

C and Javascript have the former order, Java, Ruby, and Python have the latter order.

>ORs evaluating left to right

There is only a single bitwise OR here, and no logical ORs. Whether they are evaluated left to right or right to left makes no difference in the execution of this expression.

Swap it left and right:

    (1 > 0 | 1)

And you'll see that C still gives you 1, and Python still gives you False.

>we have something that is not False ORed with True

No. We have (in the original Python equation) 1 ORed with 0. That results in 1. Then that resultant 1 is compared ('<') with 1. That comparison results in False .

The difference between Python and C is that in Python '|' has higher precedence than '<', but in C '<' has higher precedence than '|'. Dennis Ritchie admits that this is a mistake in the C language[1]. Python (and Solidity) have corrected that mistake.

The reason that '|' should have higher precedence than '<' is the same reason that '+' should have higher precedence than '<'. Namely, people want to do arithmetic calculations ('|' and '+') then compare the result of those calculations ('<' and '=='). There is essentially no situation where it is useful to have '<' have higher precedence than '|'.

[1] https://stackoverflow.com/questions/4685072/operator-precede...

Thanks for the explanation. I'm not familiar with Solidity and was assuming the intent was logical or.

There is quite a lot to criticize Solidity but this is quite a bad example. Operator precedence is often different between languages.

And because some languages miss a boolean type, you can't deduce if 1 was because of the bitwise or operator or the less-than operator.

Let's take a look at (2 | 0 < 1) instead.

C and JavaScript result in 3.

Ruby and Python return False.

Java throws a compilation error: error: bad operand types for binary operator '|'. first type: int, second type: boolean

Now which of these behaviours is the one that is the universal right one? (Hint: no one, you should always know the rules of the language you program in or if you don't, just throw in some parentheses to be on the safe side)

I fully agree. Maybe the VM and language were originally designed for faster time to market and developer adoption?

Whatever the original reasons were, it is certainly time for better tooling.

I think I read somewhere they were gonna switch to webassembly

Maybe some choices in the design can be explained with "Worse is Better" https://www.dreamsongs.com/RiseOfWorseIsBetter.html

You shouldn't be creating a language for that anyway. Even implementing smart contracts on a self-rolled blockchain touches the risk ceiling of dealing with new tech for handling people's money. Doing it with a new vm and language is just reckless.

Reply on news.ycombinator.com