我读过下面的vulnerability report in grep和the associated commit,其中所有的integer和unsigned integer都被size_t替换了。
我有一个简单的问题:用size_t替换unsigned integer是否可以避免数字溢出(或其他类型的攻击?如果是,为什么?(事实上,我看不出它有什么变化,因为我认为size_t的定义是typedef unsigned int size_t;)。
发布于 2013-02-28 03:31:23
在您的系统上,size_t可能类型定义为unsigned int,但在其他系统上可能不是这样,尤其是嵌入式(非X86)系统。根据ANSI标准,无符号整数可以小到16位。
在每个系统上定义size_t,以保证足够大,以提供该系统上任何可能的对象的大小。
在这个漏洞的情况下,我猜测(unsigned int) -> (size_t)实际上不是修复的一部分,至少在X86系统上是这样,而是相关清理的一部分,以确保不会留下任何问题。
这也是一个很好的编程实践。
发布于 2013-02-28 03:26:21
unsigned integer从不溢出。它不能。对无符号类型的运算是使用模算术完成的。所以不,用size_t替换unsigned integer不会避免任何溢出,因为使用unsigned int一开始就没有任何要避免的溢出。
作为对一些评论的回应,我的意思是“溢出”,就像标准在将“整数溢出”描述为未定义的行为时使用“溢出”一样。例如,当标准声明“在fl上的整数上的行为是欠整数行为的一个例子”时。这并不是说,当值不适合数据类型时,无符号整数会导致未定义的行为。此外,该标准还说:
涉及无符号操作数的计算永远不能超过flow,因为不能由产生的无符号整数类型表示的结果将以比结果类型可以表示的最大值大1的数字为模进行减去
(第6.2.5条第9段)
发布于 2013-02-28 03:30:34
size_t是一种能够以字节表示任何对象的大小的类型: size_t是由sizeof运算符返回的类型,在标准库中广泛用于表示大小和计数。
因此,size_t总是能够正确地表示大小,并且在这种意义上永远不会溢出。
此外,size_t可能比无符号整型更大、更等甚至更小,您的编译器可能会出于优化目的而对其进行假设。因此,size_t和unsigned int是不同的。
https://stackoverflow.com/questions/15120565
复制相似问题