Linux中的printf问题 [英] printf issue in linux

问题描述

以下是一个简单的程序，可以在HP& amp; amp;上打印格式为"1.2"的文件Linux.但是，行为是不同的.我不想扩大问题的范围，但是实际上发生此问题的程序在字符串中具有浮点值，因此不能使用％f(甚至使用sprintf).

Following is a simple program to print formatted "1.2" on HP & Linux. However, the behavior is different. I do not want to make the question bigger but the program where this is actually occurring has a float value in a string, so using %f is not an option (even using sprintf).

以前有人遇到过吗?哪种行为是正确的?

Has anyone encountered this before? Which behavior is correct?

这不应该是编译器问题，但仍然可以在gcc，icpc，icc，g ++上尝试过.

This should not be a compiler issue but still have tried it on gcc, icpc, icc, g++.

#include <stdio.h>

int main()
{
   printf("%s = [%010s]\n", "[%010s]",  "1.2");
   return 0;
}

**HP:**
cc test2.c -o t ; ./t
[%010s] = [00000001.2]

**Linux:**
icc test2.c -o t ; ./t
[%010s] = [       1.2]

非常感谢您的答复:)

推荐答案

来自glibc printf(3)手册页:

From the glibc printf(3) man page:

   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, i, o, u, x, and X), the 0 flag  is
          ignored.  For other conversions, the behavior is undefined.

因此，在基于glibc的系统上，不能期望带有 s 的 0 标志将字符串填充为带有 0 s的字符串.

So a 0 flag with s cannot be expected to pad the string with 0s on glibc-based systems.

这篇关于Linux中的printf问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！