我为 Windows 10 修复了一个 bug

本着对这个 bug 的好奇心,再加上 Windows 10 计算器是开源项目,Peter 认为解决这个问题应该不会太复杂,所以他希望亲自找到 bug 并进行修复。

他先在自己的电脑上测试看是否能复现,按照帖子的示例,在测试 7.31-12.31 的间隔天数时,计算器返回的结果是正确的 —— “5个月”。接着 Peter 稍微改了一下日期,改成 7.31-12.30 时,bug 复现了,计算器显示的值为:“5 months, 613566756 weeks, 3 days”,这明显是错误的。

,Peter 决定从 下载源码来研究一番。从 repo 把源码下载到本地后,由于在 IDE 运行 Windows 计算器项目需要 UWP workload,所以 Peter 还为 添加了 UWP workload。不过 Peter 表示搭建开发环境也十分顺利,修 bug 第一步至此完成。

接着 Peter 打开了解决方案文件(solution file),查看 “Calculator” 项目,并搜索看似相关的任何文件。他找到了界面文件DateCalculator.xaml,接着从相关的文件DateDiff_FromDate追踪到了DateCalculatorViewModel.cpp,最后找到DateCalculator.cpp

然后 Peter 开始设置断点并观察相关变量的变化,他发现 final 变量DateDifference 的值有误。因此他判断这个 bug 不是由转换为字符串存在错误而导致的,而是实实在在的计算错误。

既然计算存在问题,那就看看它的计算逻辑是如何实现的。

用伪代码表示如下:

DateDifference calculate_difference(start_date, end_date) { uint[] diff_types = [year, month, week, day] uint[] typical_days_in_type = [365, 31, 7, 1] uint[] calculated_difference = [0, 0, 0, 0] date temp_pivot_date date pivot_date = start_date uint days_diff = calculate_days_difference(start_date, end_date) for(type in differenceTypes) { temp_pivot_date = pivot_date uint current_guess = days_diff /typicalDaysInType[type] if(current_guess !=0) pivot_date = advance_date_by(pivot_date, type, current_guess) int diff_remaining bool best_guess_hit = false do{ diff_remaining = calculate_days_difference(pivot_date, end_date) if(diff_remaining < 0) { // pivotDate has gone over the end date; start from the beginning of this unit current_guess = current_guess - 1 pivot_date = temp_pivot_date pivot_date = advance_date_by(pivot_date, type, current_guess) best_guess_hit = true } else if(diff_remaining > 0) { // pivot_date is still below the end date if(best_guess_hit) break; current_guess = current_guess + 1 pivot_date = advance_date_by(pivot_date, type, 1) } } while(diff_remaining!=0) temp_pivot_date = advance_date_by(temp_pivot_date, type, current_guess) pivot_date = temp_pivot_date calculated_difference[type] = current_guess days_diff = calculate_days_difference(pivot_date, end_date) } calculcated_difference[day] = days_diff return calculcated_difference }

上面的代码主要做了这些事:先算出相差的年数、然后计算相差的月数、接着计算相差的周数、最后计算相差的天数。

Peter 表示这看起来很正常,他没发现其中的逻辑存在错误。

问题正是在于此,写这段代码的人以为代码会按预料中执行:

date = advance_date_by(date, month, somenumber)date = advance_date_by(date, month, 1)

逐一运行后如下:

date = advance_date_by(date, month, somenumber + 1)

常见情况下的确如此。

但问题在于:“如果起始日期为某月的第 31 天,结束日期所在的月份只有 30 天,该以哪天作为结束的标志?”对于 来说,它的答案显然是“在第 30 天”。

具体而言,这就意味着:

“July 31st + 4 Months = November 30th”
“November 30th + 1 Month = December 30th”

然而实际情况是:

“July 31st + 5 Months = December 31st”

这就引起了“差一错误”。逐步调用Window::Globalization::Calendar::AddMonths会导致GetDifferenceInDays出现负值,然后将其分配给无符号变量daysDiff,经过后面的循环迭代后,daysDiff会将这个负值变为更大的数字。

接着 Peter 在 Windows 计算器的 GitHub 仓库 以进行最小化“修复”。

Peter 为修复加上了引号,是因为它最后计算出的结果如下:

Peter 表示,如果各位认可“7月31日+ 4个月= 11月30日”这样的结果,他认为这在技术上是正确的。虽然完整的结果不符合大众对日期间隔天数的阅读习惯,但至少不会出错。

不过这件事中,最令人深刻的是最后合并了 Peter 以修复这个问题。

这说明微软的开源项目不仅仅是将代码托管在 GitHub 而已,而是会听取来自社区用户的建议和改进。

那么问题来了,如果是你,你会怎样解决这个错误呢?