[🐛Bug]: 780epv对于数据的打印或许存在问题

描述一下这个bug / Describe the bug

780epv试图打印一个s32的过程中发现对于大数字很难打印出准确的数值，例如4294967295（0xffffffff）,打印结果为一个科学计数法表示的数字，而且这个数字转化为字符串后仍为一个小数和e的多少次方的形式，那么如果是一个未知的大数据那么就无法得知其具体数值

复现步骤 / To Reproduce

    print(4294967295)
    print(tostring(4294967295))

打印结果
[2024-04-23 14:33:46.091][000000001.777] 4.294967e+09
[2024-04-23 14:33:46.092][000000001.778] 4.294967e+09

如果正常，应该是什么样 / Expected behavior

应为正确的数值

截图 / Screenshots

输入图片说明

日志 / Logs

[2024-04-23 14:33:46.091][000000001.777] 4.294967e+09
[2024-04-23 14:33:46.092][000000001.778] 4.294967e+09

PACK包版本 / Version

1.0.0.1

验证

检查过该问题，之前没有人提过 / Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
提供了最小可复现工程或详细的复现步骤，确保开发者可以复现 / The provided reproduction is a minimal reproducible example of the bug.
已经提供了完整的报错信息、日志、截图，没有经过删减。

题外话，顺便问一下直接print(0xFFFFFFF）为什么打印值是-1，而不是4294967295

%d和%u的差别，不影响值本身的正确性

明白了谢谢，那对于上面说到的一个大的数据的打印有什么好的方法吗

mcu.x32看一下行不行，不行的话大概只有string.format这条路了

我这边还是使用的4294967295进行测试，mcu.x32会报错number has no integer representation，似乎这样的数字不是以整数的方式存储的，我使用string.format("%d",4294967295）也会报相同的错误，使用%f才能输出4.294967e+09与直接print的结果是相同的，但是精度上仍不足，使用%8f也无法提升精度

mcu.x32(0xffffffff)

明白了谢谢

GVP 合宙Luat / LuatOS

内容风险标识