lrealpath返回的值少了一个字符

[ushen-pyj]

r 39
fullname D:\workshop\lua\tetris-soluna\main.game
push result D:\workshop\lua\tetris-soluna\main.game
push len 38
[2025-09-16 22:57:22.52]INFO startup 5
[2025-09-16 22:57:22.52]INFO startup 6
[2025-09-16 22:57:22.52]INFO startup 7
[2025-09-16 22:57:22.52]INFO filename main.game
[2025-09-16 22:57:22.52]INFO realname D:\workshop\lua\tetris-soluna\main.gam
[2025-09-16 22:57:22.52]INFO curpath D:\workshop\lua\tetris-soluna
[2025-09-16 22:57:22.52]ERROR Can't open D:\workshop\lua\tetris-soluna\main.gam

前面的日志是我在lrealpath函数打印的
lua的settings_filename函数获取到的realname少了一个字符

[cloudwu]

已修。bug 是这样引入的：

在做 lfs.dir 时发现 windows 下转换为 utf8 串的文件名多了一个 '\0' ，发现 WideCharToMultiByte() 返回长度时把结尾的 \0 算进去了。 679df12

实际只有在传入 -1 时，这个 api 自己统计字符串长度才会计入末尾 0 。

realpath 先用 GetFullPathNameW() 返回的字符串长度，它不含末尾 0 。

[cloudwu]

补：后面又发现几处 off by 1 的相关错误，是因为之前修这个问题比较敷衍造成的。
bd783c7
21c2e78

[cloudwu]

检查了所有的 windows_filename() 和 utf8_filename() 调用，改掉了所有的 +1/-1 。

终于想起来之前为什么会这么写：

因为 windows api 在转换字符串时，如果传入了数据长度，会按这个长度转换。如果没有传入结尾的 0 ，那么转换结果也没有。如果传入了 -1 ，长度会计入结尾 0 。

在很多调用环境，其实我假定了最后有 0 结尾（保证是一个 C string）。

最后一次修改，统一了这些地方的使用。