我为 Windows 10 修复了一个 bug
副标题[/!--empirenews.page--]
本文讲述了一名开发者为 Windows 计算器应用修复 bug 的经历。 据这名开发者(下用 Peter 代称)介绍,他某日在 Reddit 闲逛时,一个位于 Windows 10 子版块下的帖子引起了他的注意。帖子内容如下: 和大家一样,在计算两个日期之间的相隔天数时,Peter 也发现了关于周数的描述明显是错误的,如此大的数值看起来应该是上溢或者下溢之类的问题,要不就是差一错误(off-by-one)等常见的逻辑错误。 本着对这个 bug 的好奇心,再加上 Windows 10 计算器是开源项目,Peter 认为解决这个问题应该不会太复杂,所以他希望亲自找到 bug 并进行修复。 他先在自己的电脑上测试看是否能复现,按照帖子的示例,在测试 7.31-12.31 的间隔天数时,计算器返回的结果是正确的 —— “5个月”。接着 Peter 稍微改了一下日期,改成 7.31-12.30 时,bug 复现了,计算器显示的值为:“5 months, 613566756 weeks, 3 days”,这明显是错误的。 确定了 bug 的存在,Peter 决定从 Windows 计算器的 GitHub 仓库下载源码来研究一番。从 repo 把源码下载到本地后,由于在 IDE 运行 Windows 计算器项目需要 UWP workload,所以 Peter 还为 Visual Studio 添加了 UWP workload。不过 Peter 表示搭建开发环境也十分顺利,修 bug 第一步至此完成。 接着 Peter 打开了解决方案文件(solution file),查看 “Calculator” 项目,并搜索看似相关的任何文件。他找到了界面文件 然后 Peter 开始设置断点并观察相关变量的变化,他发现 final 变量 既然计算存在问题,那就看看它的计算逻辑是如何实现的。 Windows 计算器对间隔日期的计算逻辑用伪代码表示如下:
上面的代码主要做了这些事:先算出相差的年数、然后计算相差的月数、接着计算相差的周数、最后计算相差的天数。 Peter 表示这看起来很正常,他没发现其中的逻辑存在错误。 (编辑:上海站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- Windows 11部分驱动可追溯至1968年 微软做出说明回应
- windows-7 – 如何通过GPO禁用Windows 7中的Tcp / Ip设置?
- windows-server-2008 – SSD能否通知主机操作系统其磨损程度
- 如何通过命令行升级Debian 9为Debian 10
- 微软Windows11 Dev 22543.1000预览版上线 修复任务管理Bug
- Windows 11频发MSI崩溃难题 微软紧急推送补丁修复
- R读一个巨大的csv
- windows-server-2012 – 如何在Windows Server 2012上隐藏回
- windows-server-2003 – Windows – 一步发布和续订IP?
- windows-server-2003 – 将Perfmon计数器名称放入文本文件的