转载

忽视数值类型的长度范围而造成的问题代码原荐

在日常编程中，我们可能经常简单的处理不同数值类型，而忽视其能表示的长度范围，比如int和long，我们可能经常将这两种类型混用，然后遇到编译报错，就用强制转换来应付。但通过我最近遇到的两个代码所暴露出的问题，发现这种做法是不严谨的。

首先看代码1（java代码），某广泛使用的即时通讯SDK所声明的接口

// 返回第i个元素
	public TIMElem getElement(int i) {
	   // 实现代码省略
    }

	// 返回元素的个数
    public long getElementCount() {
	   // 实现代码省略
    }

这段代码的问题在于：取元素时下标的数值范围和元素数组的长度不一致，我们知道在java中，int表示的范围是-2^31~2^31-1，long的范围式-2^63~2^63-1，那么如果元素个数大于int能表示的最大值，则 getElement是无法取到所有的元素的。那么sdk的demo是怎么使用这个接口的呢？

List<MessageInfo> list = new ArrayList<>();
        for (int i = 0; i < timMessage.getElementCount(); i++) {
            final MessageInfo msgInfo = new MessageInfo();
            if (ele2MessageInfo(msgInfo, timMessage, timMessage.getElement(i), isGroup) != null) {
                list.add(msgInfo);
            }
        }

这段代码的问题在于，如果getElementCount()的值大于int的最大值，即2^31-1（虽然实际情况不可能出现这样的场景），则getElement的参数会为负数，很可能造成异常。

再看看第二个问题的代码，也是java代码

class XXXItem implements Comparable{
    // 成员变量，long类型
    private long mTime;
	
	public long getTime() {
        return mTime;
    }
	
    // 实现了一个用于比较大小的接口
	@Override
    public int compareTo(@NonNull XXXItem item) {
        return (int) (item.getTime() - this.getTime());
    }
   }

Comparable的用法，熟悉java的人应该都比较清楚。这里的问题就是出在compareTo上，getTime()返回值是long类型，两个long类型相减，并将结果强制转换为int，可能会造成溢出，从而违背该代码的本来初衷。其实java标准库中的Long类已经给出了比较long的方法，，可以直接调用，它实现的也很简洁。

public final class Long extends Number implements Comparable<Long> {
	    public static int compare(long x, long y) {
        	return (x < y) ? -1 : ((x == y) ? 0 : 1);
    	}
	}

思考

关于溢出造成的不安全代码并不罕见，在《深入理解计算机系统》这本书中的2.3节就有介绍，里面还举例了FreeBSD的代码库中就曾经存在这种存在安全隐患的代码。我觉得出现这种问题的本质还是因为：计算机科学家在设计补码这种数值表示方式时，是允许溢出这种现象存在的，有些程序逻辑甚至需要溢出来实现，但程序员在开发时，忽略了溢出的存在，而仅凭直觉去写代码，从而造成了这种隐患。因此我觉得我们在日常写代码时要注意：