wrong output of printf(%ld) (64-bit)

[上田 弘信]

Hi,
My printf(%ld) program outputs wrong number.
Could you tell me why?

This is my code.

tr1v2db 301: cat main2.cpp
#include
int main()
{
char buf[4096];
const char* str = "string";
//const char* format = "str : %s, d : %d, d : %d"
// ", str : %s, d : %d, d : %d"
// ", str : %s, d : %d, d : %d";
const char* format = "str : %s, ld : %ld, ld : %ld"
", str : %s, ld : %ld, ld : %ld" // *1
", str : %s, ld : %ld, ld : %ld";

printf(format, str, 1, 2,
str, 3, 4, // *1
str, 5, 6);
std::cout << buf << std::endl;
return 0;
}

This program outputs like this.
tr1v2db 320: ./a.out
str : string, ld : 1, ld : 2, str : string, ld : 3, ld : 4, str : string, ld : -9223367643103231995, ld : -9223367643103231
994

I found that deleting the 2 lines (marked by *1) output right number.
And by using %d instead of %ld, I can get right number, too.

Sorry my broken english.
Thanks! yoshi

[John Poff]

Hi Yoshi,

I'm not a C++ guy, so I can't help much with the code. There is a patch for printf for 11.00. Do you have this one installed on your system?

Patch Name: PHCO_27340


Patch Description: s700_800 11.00 printf(1) cumulative patch



JP

[上田 弘信]

Sorry, I use...
OS : HP-UX 11.0
copiler : aCC 3.31
Build with +DA2.0W option

[上田 弘信]

Thank you, John.

I think, the patch you showed is not installed on my system.
I try to install the patch.

Thank you for your rapid reply.
Yoshi.

[上田 弘信]

Hi,

I installed the patch, but it takes no effects...

I look back to the code above, I find that deleting the line (std::cout << buf << std::endl) gets right number.
(this line is meaningless, but why this affects to the printf()'s output? mmm...)

I find other code that results in the same as above. (sprintf() version)

tr1v2db 174: cat main3.cpp
#include
int main()
{
char buf[4096];
const char* str = "string";
const char* format = "str : %s, ld : %ld, ld : %ld"
", str : %s, ld : %ld, ld : %ld"
", str : %s, ld : %ld, ld : %ld";

sprintf(buf, format, str, 1, 2,
str, 3, 4,
str, 5, 6);

std::cout << buf << std::endl;
return 0;
}

tr1v2db 175: aCC +DA2.0W -AA -g main2.cpp
tr1v2db 176: ./a.out
str : string, ld : 1, ld : 2, str : string, ld : 3, ld : 4, str : string, ld : -
9223367643103231995, ld : -9223367643103231994

Would anyone give me any clue (hint, info, etc.)?
I will sincerely appreciate it.

Thanks! yoshi

[上田 弘信]

Hi,

Sorry, compiling not main2.cpp but main3.cpp...

tr1v2db 177: aCC +DA2.0W -AA -g main3.cpp
tr1v2db 178: ./a.out
str : string, ld : 1, ld : 2, str : string, ld : 3, ld : 4, str : string, ld : -
9223367643103231995, ld : 6

[John Poff · Accepted solution]

Hi again,

I got your code to work. I changed

char buf[4096];

to read

static buf[4096];

and it worked. As I said earlier, I'm not even a C++ novice. I happened to find a thread with a question about sprintf that Clay Stephenson answered [a real wizard!]. Clay told someone else to put 'static' in front of a variable declaration to solve an sprintf problem. Here is the other thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x1cd394f22a31d6118fff0090279cd0f9,00.html

Maybe Clay will see this thread and stop in to explain to you what really happened here.

JP

[上田 弘信]

Thank you, John.

Wow, with "static" keyword as you told, I can get the right number!

Sorry but..., I don't understand why the "static" keyword fixed the problem.
It worked ... but, it might be worked by accident...

The other thread you showed is different from my case a little bit.
I want to use "buf" within the function rather than out of scope of function.
From the view of sprintf(), no matter where "buf" is on the stack or on the heap, there is no difference, I think...

But, I can get a big clue thanks to you.
Thank you for your helping hand!

I'm waiting for any any info.
Thanks! Yoshi.

[Volker Borowski]

Hi Yoshi,

I do a bit of speculating here, but anyway...

The difference between heap and stack might result from diffrent implicit datatypes for the definition of "buf".
On the heap it might be implicitly a 64bit pointer, while on the stac it might be a short pointer. This might result in other handling of implicit type conversion.

While long will not be the implicit datatype of a constant in the source code, I would first go by explicitly typecast the constants, so that you are sure no compiler implicit stuff is done.

So instead of ", 1," go like ", (long) 1," !
You should increase the warning level of the compiler and I am sure you will get messages of implicit type casts, which might not match your expectations.

", 1," will be typecasted during compile time and may be only a 32 bit integer is chosen. While in the compiled code you will only find a pointer to this value, "%ld" might tell printf to address the correct pointer, but read 64 bit from this address, which will be additionl 32 bit of uninitialized rubbish.

But again,
just speculating
Volker

[上田 弘信]

Thank you, Volker.

The type of value of 1,2,... in my code is int (32-bit), I think too.
With typecasting (like "(long) 1"), I can get right number.
And as mentioned above, using "%d" will be good.
So, it would be better to use "%d" for int-value and to use "%ld" for long-value correctly, I think...

But...
SHOULD I use "%d" or "%ld" correctly according to the type of argument of sprintf()?
Or, I will have undefined behavior?
If you know whether it is right or not, please tell me.

I think your idea of additional 32 bit rubbish is possible.
But, almost of expected value is outputted correctly, and (-9223367643103231995 is 800003FF00000005(HEX)) I don't see where the value '800003FF' come from...
If all outputted value contains rubbish, things will be understood easily...
I want to know what happens in detail when calling sprintf() and processing within sprintf().
Would anyone tell me where a kind of specification of sprintf() is?

Thanks!
Yoshi.

[上田 弘信]

Hi, Everyone.

I have found related web-links.
http://h21007.www2.hp.com/hpux-devtools/CXX/hpux-devtools.0108/0037.html
http://devrsrc1.external.hp.com/STK/impacts/i447.html
So, I should use "%d" for int-value and "%ld" for long-value.
I will modify my old code so.

Volker, you are right, I think.
With gdb, I find the value 0x800003ff and 0x00000005 in the stack.
The value 0x800003ff is uninitialized rubbish in the stack.
Sprintf() reads 64 bit from the address, and outputs it through.

Here is a log of gdb.

Breakpoint 1, main () at main3.cpp:5
5 const char* str = "string";
(gdb) n
6 const char* format = "str : %s, ld : %ld, ld : %ld"
(gdb)
10 sprintf(buf, format, str, 1, 2,
(gdb) display/i $pc
1: x/i $pcoqh 0x40000000000082a4

: ldo -0x10d8(%sp),%r26
(gdb) stepi
0x40000000000082a8 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082a8

: ldd -0x10e0(%sp),%r25
(gdb)
0x40000000000082ac 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082ac

: ldd -0x10e8(%sp),%r24
(gdb)
0x40000000000082b0 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082b0

: ldi 1,%r23
(gdb)
0x40000000000082b4 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082b4

: ldi 2,%r22
(gdb)
0x40000000000082b8 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082b8

: ldd -0x10e8(%sp),%r21
(gdb)
0x40000000000082bc 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082bc

: ldi 3,%r20
(gdb)
0x40000000000082c0 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082c0

: ldi 4,%r19
(gdb)
0x40000000000082c4 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082c4

: ldd -0x10e8(%sp),%ret0
(gdb)
0x40000000000082c8 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082c8

: std %ret0,-0x50(%sp)
(gdb) x/xw $sp-0x50
0x800003fffeff18d0: 0x800003ff
(gdb)
0x800003fffeff18d4: 0xfefedfa8
(gdb)
0x800003fffeff18d8: 0x800003ff <-- look! rubbish of stack
(gdb)
0x800003fffeff18dc: 0xfee8de80

From 1st to 8th arguments of sprintf() is set to register %r26 - %r19 respectively.
These registers is 64bit-length.
Sprintf() uses these register, I think.
This is why "for the first 8 params, it would probably work." (cited from first web-link above), I think.

(gdb) stepi
0x40000000000082cc 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082cc

: ldi 5,%ret0
(gdb) stepi
0x40000000000082d0 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082d0

: stw %ret0,-0x44(%sp)
(gdb) stepi
0x40000000000082d4 10 sprintf(buf, format, str, 1, 2,
1: x/i $pcoqh 0x40000000000082d4

: ldi 6,%ret0
(gdb) x/xw $sp-0x50
0x800003fffeff18d0: 0x40000000
(gdb)
0x800003fffeff18d4: 0x00005f78
(gdb)
0x800003fffeff18d8: 0x800003ff <- rubbish remains
(gdb)
0x800003fffeff18dc: 0x00000005 <- value 5 is stored on stack

From 9th arguments of sprintf() are stored on stack aligned every 8byte.
The rubbish remains uninitialized.

Thanks a lot to John, Volker and all of those who listen to me.
Yoshi.