printf issue in linux

Question

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?

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]

Edit: Thank you all very much for the responses :)

score 7 · Accepted Answer · answered Sep 07 '11 at 05:55

7

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.

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

answered Sep 07 '11 at 05:55

Ignacio Vazquez-Abrams

776,304
153
1,341
1,358

3

I think the key thing here is that the behavior is undefined, so the fact that he gets different results between HPUX and Linux is perfectly understandable. – Brian Roach Sep 07 '11 at 05:57
1

This is part of linux porting project. Hence the inherent requirement is that we need to match exactly what HP does :( – Sudeep Sep 07 '11 at 09:01

Michael Foukarakis · Answer 2 · 2011-09-07T06:13:36.963

2

According to the man page, the behaviour of the 0 flag for anything other than d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversions is undefined. So both are fine.

EDIT: When I say "fine", I mean from the compiler/libc standpoint. From your application's point of view, the behaviour you're relying on (on both Linux & HP) is a bug and you should do your formatted printing correctly.

edited Sep 07 '11 at 06:13

answered Sep 07 '11 at 05:57

Michael Foukarakis

39,737
6
87
123

In our case the behavior in HP is the reference. May be I have explore the option of using %f using sprintf and store it as 0 padded string and then use printf. – Sudeep Sep 07 '11 at 09:06

score 1 · Answer 3 · answered Sep 07 '11 at 05:55

1

If you don't want leading zero fill, omit the leading zero fill indicator:

printf("%s = [%10s]\n", "[%010s]",  "1.2");

It is somewhat surprising that an implementation honors filling a string with zeros, but it is easily corrected.

answered Sep 07 '11 at 05:55

wallyk

56,922
16
83
148

I need the leading 0 padding :) – Sudeep Sep 07 '11 at 09:39

score 0 · Answer 4 · edited May 23 '17 at 12:29

0

Adding to what Ignacio Vazquez-Abrams said, according to the documentation for printf, the result of what you are doing is undefined behavior. The fact that two OSes produce different results is not unexpected.

In fact, compiling your code with gcc 4.5.2 on Ubuntu gives the following warning:

warning: '0' flag used with ‘%s’ gnu_printf format

edited May 23 '17 at 12:29

Community

1
1

answered Sep 07 '11 at 06:01

Brian Roach

76,169
12
136
161

printf issue in linux

4 Answers4

Linked