为什么scala围绕Integer Overflow设计？
|
我是一名前
Java开发人员,最近我观看了Venkat Subramaniam教授(
https://www.youtube.com/watch?v=LH75sJAR0hc)为Java开发人员提供的有趣的Scala介绍.
引入的一个要点是消除声明的类型而不是“类型推断”.据推测,这意味着高阶编译器通过上下文识别我打算使用的类型. 作为交易的应用程序安全专家,我试图做的第一件事就是破解这种类型的推理……例如： // declare a function that returns the square of an input Int. The return type is to be inferred. scala> val square = (x:Int) => x*x square: Int => Int = <function1> // I can see the compiler inferred an Int for the output value,which I do not agree with. scala> square(2147483647) res1: Int = 1 // integer overflow 我的问题是为什么编译器没有看到“*”是一个有溢出威胁的运算符,并将输入包装成像BigInteger一样更具保护性的东西？ 根据教授的说法,我应该忘记内部实现,然后继续我的业务逻辑.但是在我的快速演示之后,我不太确定Scala对于那些不了解编译器在我的方法中做什么的程序员来说是安全的. 解决方法
我认为@rightf?ld在某种程度上夸大了溢出发生或不发生的频率(特别是在考虑一个积极试图溢出你的攻击者时).但我同意他的基本观点.将所有数学转换为BigInteger几乎肯定会对Java产生巨大的性能影响.对于开发人员来说,选择这样一种语言,他们必须得到一些可见的成本.
对于许多操作,字符串对象比cstrings具有小得多的性能开销.它们还为开发人员提供了非常明显的好处,这就是人们使用它们的原因,而不是安全性本身.字符串对象很容易在cstrings上做很多常见的事情. BigInteger没有提供这些.它只需要一小部分速度完全相同的代码,但不会溢出(很少有开发人员日常看到的错误,即使安全人员经常看到它). 等效的是一个cstring(strcmp,strcpy,strcat等)以一小部分速度运行,但只是不需要null终止符.我不认为很多人会跳过使用它,无论多少都有助于安全性,而不是以空终止的字符串.如果语言需要它,我不会看到很多人急于使用这种语言. 正如@rightf?ld在评论中所暗示的那样,与Java的互操作性将会被破坏,因为大多数(如果不是全部)数字都会成为BigInteger.您不断进行转换,这会增加溢出的相同危险,同时增加大量代码复杂性(以及更多性能影响). 如果该语言具有许多其他引人注目的功能,那么从头开始语言可能会随处可见BigInteger(如python),但是将一种语言改造成希望自然转换为(和使用Java)的语言是一件非常困难的事情. . （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |