以下是在HP和Linux上打印格式化为“1.2”的简单程序。 但是，行为是不同的。 我不想让这个问题变大，但是这个实际发生的程序在string中有一个浮点值，所以使用％f不是一个选项（即使使用sprintf）。
有没有人遇到过这个？ 哪种行为是正确的？
这不应该是一个编译器的问题，但仍然尝试过在gcc，icpc，icc，g ++。
#include <stdio.h> int main() { printf("%s = [%010s]n","[%010s]","1.2"); return 0; } **HP:** cc test2.c -ot ; ./t [%010s] = [00000001.2] **Linux:** icc test2.c -ot ; ./t [%010s] = [ 1.2]
编辑：非常感谢你的回应:)
我怎样才能下载前一天有个名字的文件？
sudo -E不通过PYTHONPATH
Linux内核调度
将文本从nano编辑器复制到shell
使用单个bash shell命令获得gb中的可用内存
与Clang编译时，链接程序无法在64位Mint OS下find32位库
使用Scipy最小化数据线性组合的function
硬中断和softirq
从glibc printf(3)手册页：
0 The value should be zero padded. For d,i,o,u,x,X,a,A,e,E,f,F,g,and G conversions,the converted value is padded on the left with zeros rather than blanks. If the 0 and - flags both appear,the 0 flag is ignored. If a precision is given with a numeric conversion (d,and X),the 0 flag is ignored. For other conversions,the behavior is undefined.
所以不能期望有s的0标志在基于glibc的系统上用0来填充字符串。
根据man页，除了d，i，o，u，x，X，a，A，e，E，f，F，g和G转换之外， 0标志的行为是不确定的。 所以两者都很好。
编辑：当我说“好”，我的意思是从编译器/ libc的角度来看。 从您的应用程序的角度来看，您所依赖的行为（在Linux和HP上）是一个错误，您应该正确地进行格式化打印。
如果您不想要前导零填充，请忽略前导零填充指示符：
printf("%s = [%10s]n","1.2");
有一个令人惊讶的实现是用零来填充字符串，但很容易纠正。
除了Ignacio Vazquez-Abrams所说的，根据printf的文档，你所做的事情的结果是未定义的行为。 两个操作系统产生不同的结果这一事实并不意外。
实际上，在Ubuntu上编译gcc 4.5.2的代码给出了以下警告：
警告：与'％s'gnu_printf格式一起使用'0'标志
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
