在printf和vsnprintf中处理64位无符号问题

之前，我曾用XC32版本1.42和1.43测试了64位整数，没有“问题”，但是我的风格和你们的有点不同。当运行一点点代码时，我发现：显然，当使用SNPrTfF（）时，把一个字符串放在RAM中的数组中，比如说PCSTR，XC3。如果使用PrTNF（PCSTR），2会变得非常混乱。我将在一分钟内展示一些结果。事实上，我不记得使用这样的“原始”PrTrF（因为我认为是与编译器“问题”无关的好理由）。我通常使用PrpTF（“%s”，PCSTR），所以我不知道你正在观察的问题。（也请注意，我没有运行所有的测试代码，所以我不知道是否还有其他编译器问题。）最后注意到下面我描述的bug实际上并没有破坏其他的。64位变量，但是如果在使用“原始”PrtTF的程序中的任何地方尝试“%LLU”的PrtTF，它会变得混乱。奇怪，但却是真的。至少这就是我所看到的。总之，这里有一点我的测试代码。我已经在文件中定义了有用的RavaPrimtf（或不是）。这些测试在PIC32 MX795F512L上输出：当USER RaWyPrrtf不被定义时，输出-对我来说是好的。在4月26日的2017，在09:4:15，用XC32版本1430siZeof（T64）＝8开始：T64＝10000（0x000）。TES（T64）字节为10000（0x000），未定义10（27×00 00 00 00 00 UsIX RAWAI PrimTf），使用PrtTf（“%s”，PCSTR）；TESTA3SNPrTNFF＝10000（限位32位），在TESTA3: T64＝10000（0x000 000），调用PrdTyLL字节（T64）字节10000（0x000）。定义为——大问题。在2017年4月26日09:58:42用XC32版本1430sizeof(t64)=8Initi.:t64=2684485281(0x00002710)调用print_llbytes(t64)字节0(0x00002710)：使用printf(pcStr)定义10 27000 00000000USE_RAW_PRINTF：TestA3 snprintf=10000(Limited32bit)A在testA3:t64=2684485281(0x00002710)调用print_llbytes(t64)Bytes 0(0x00002710)：102700000000000000之后，注意64位整数的字节可以，只是带有“llu”的printf是错误的。甚至在调用snprintf之前也是错误的，所以我认为问题不在于snprintf本身，而在于编译器如何看待事物。或者，也许是别的问题——我不想太深入地关注编译器-编写器的思想。（参见脚注）[编辑]这些测试与未经检查的传统LIBC。当我使用传统的LIBC时，输出看起来不错。（当然，除非您定制了write()函数，否则必须使用“rn”而不是“n”。）我通常避免使用Legacy libc还有其他原因。在我看来，这是一个全新的错误在1.43。就在他们“几乎”印对了长双打的时候，现在长音就不那么健康了。噢，好吧。[/编辑]关于与怪物搏斗的人应该小心，以免他变成怪物。如果你长时间地凝视深渊，深渊也会凝视你。--Friedrich NietzscheBeyond Good与邪恶

我对snprintf、原始printf、XC32v143（Legacy从未启用）没有问题。我还尝试了格式化的printf（“%s”，pcStr），并得到了完全相同的输出。我的问题只是在printf和vsnprintf通过uint64_t并使用%lluTempional时出现问题。“%LLU”，T64），在我的主PrimTF中使用PCSTR21代替T64.HMMMM。

尼采& 3；尼采

亲爱的Microchip请为xc32编译器附带的标准C库创建一个测试平台。测试平台应该至少包括：-所有printf函数（printf、a sprintf、fprintf、sprintf、snprintf、vfprintd、vprintf、vsnprintf、vsprintf…）的测试格式说明符的大小和类型.-所有SCANF函数的测试（SCANF，sSCANF，VFSCANF，VSCANF，VSCANFF，…）具有修饰符和格式说明符的类型的所有组合。-所有math.h函数的测试。-所有x-to-y函数的测试（atof、atoi、atol、atoll、atoll、atoll、strtod、strtof、strtol、strtoll、strtoul、strtoul、…）对于所有这些测试中的值，如果适用的话，至少使用一个典型的、一个相当大的、一个相当小的（接近0）和一个负值。请注意，上面请求中“all”一词的每个用法都被明确地强调了。这不是一个大任务。一个人肯定能在不到一个月的时间内完成。但这确实有帮助。在此之后，请首先公布所有的发现，然后开始为下一个编译器版本修复它们。如果确实需要，那么决定哪个库或编译器标志不支持某个函数或某个函数的特定特性，但至少要清楚地记录下来。

以下来自Microchip的回复解决了这个问题-使用Legacy Library，我的测试代码都给出了正确的输出。-我必须更仔细地检查Readme文件的发行版。-Readme.html安装在这里：C:Program Files(x86)Micro.xc32v1.43docs-Warning：Legacy LibC在缺省情况下没有被选中用于我刚才使用的新项目：-MPLABXv355或MPLABXv360、XC32v143、HarmonyV202b、MHCv2024Paul---Micro.reply for ticket on类似问题----请m m确保你在项目中使用“传统的LIBC”。在MPLAX IDE中使用“传统LIBC”选项在“XC32（全局选项）”对话框中。传统LIBC是与XC32 V1.41和更高版本链接的默认C库。编译器中的这个更改在编译器自述文件中记录为：Legacy LibC default——遗留的标准C Lib现在是默认libc。这种LIBC实现为STDIO函数（如Prtff（））和SCAN（）提供了改进的功能。这个库已经被增强以支持XC32的智能IO V2特性。此外，这个LibC实现提供了更健壮的malloc()算法，包括防碎片化和改进的局部性机制。如果您希望使用与早期XC32版本相同的LibC，那么在编译和链接时将新的-no-.y-libc选项传递给xc32-gcc。还可以在“XC32 GCC”“附加选项”下使用“-FNO短双”选项。（-FNO短双）：默认情况下，编译器使用与浮点相当的双类型。此选项使双等效为长双倍。如果模块直接通过参数通道共享双倍数据，或者间接通过共享缓冲区空间共享双倍数据，则跨模块混合此选项可能会产生意想不到的结果。图书馆提供了具有开关设置的产品功能。如果您还有问题，请将示例项目放在zip文件（包含c文件、asm文件、h文件、MPLAB X项目）中，以便我们对问题进行评估。请发送一个演示项目的削减项目。如果缩减项目是不可能的，请发送复制项目的完整项目。该项目将用于调试目的并复制该问题。

相关问题：在printf%lu%llu%ld%lld等上跟踪字符。-Set：Project-Properties-XC32-gcc-.-Additional Options：[-msmart-io=0]-修复%lu%llu%ld%lld等之后的跟踪字符。也就是说，printf(“%lun”，1000L)打印“1000u”而不是“1000”——“Use Legacy Libc”应该是新项目的默认值，但是即使当我使用MPLABXv3.61和XC32v1.43创建新项目时，它也没有被选择——如果在XC32下禁用“Use Legacy LibC”，那么这些打印是正确的，但是64位n未打印的打印错误（见上文）

Hiit似乎XC32 v1.44解决了上述问题。下载可用（即使它说XC32 v1.43到今天为v1.44）固定在MPLLAB∈XC32 v1.44XC32-720中，在MPLLABXC32v1.43版本中，链接器错误地将输入对象文件中的所有符号视为弱的。这意味着非弱符号不能重写弱符号。弱符号和非弱符号的正确行为已经恢复。XC32-709在编译和链接Smart IO和Legacy Libc时，printf()和相关函数可能打印不正确的输出。在某些条件下，可以打印格式说明符。这个问题已经解决了。当将相干属性应用到零大小的区段时，RROR。（Ex：uint8_t_.((.))ary[0];）当链接器不能仅分配非零大小的部分时，它现在发出一个错误。