uint32_t has 28 bits instead of 32 bits

Question

I've encountered a confusing situation. I have this simple addition inside my code:

temp = thi + t2lo;

I have defined thi and t2lo as uint32_t in my code and temp as uint64_t:

uint32_t thi, tlo, t2hi, t2lo;
uint64_t temp = 0;

My code doesn't work properly, so I use gdb to figure out what is going wrong. When I tried to print variables in gdb I've got:

(gdb) p/x temp
$1 = 0xfeffff2
(gdb) p/x thi
$2 = 0xff00000
(gdb) p/x t2lo
$3 = 0xfffffff2

As you can see here, thi has 28 bits instead of 32 bits, and the addition result is completely wrong. Could anyone tell me what is going on here?

PS: I have a large code and I cannot put my whole source code here for you guys to reproduce this situation. Also, this situation only occurs for certain inputs and most of the time my code is working correct. I just want to check with you guys if you encountered something like this before. Any help would be greatly appreciated.

Don't put _all_ your code here, just write a small example that shows the problem. If you can't, if the problem disappears when you remove the rest of the code, then it is probably caused by something in that rest of the code, and it will be very hard for us to guess what. — Thomas Padron-McCarthy, Dec 03 '15 at 00:28
When I print 10 in decimal it only comes out as `10`. Oh no, that means `int`s can only hold numbers up to 99! — user253751, Dec 03 '15 at 00:44
@immibis: `99!` does not fit in an `int` on most architectures... — chqrlie, Dec 03 '15 at 00:45
@chqrlie I had assumed most people were smart enough to distinguish between the factorial operator and punctuation. Perhaps I was wrong. — user253751, Dec 03 '15 at 00:47
Use `temp = (uint64_t) thi + t2lo;` to get that carry into `temp`. — chux - Reinstate Monica, Dec 03 '15 at 00:54

score 4 · Answer 1 · answered Dec 03 '15 at 00:33

4

temp = (uint64_t)thi + t2lo;

Without the cast (or something equivalent) the addition will be performed in 32b, then the result extended to 64b. Which is in fact what you are seeing 0xff00000 + 0xfffffff2 = 0x10FEFFFF2 which in 32b arithmetics equals 0xFEFFFF2.

answered Dec 03 '15 at 00:33

dxiv

16,984
2
27
49

I used cast but it didn't work. The result is still incorrect – A23149577 Dec 03 '15 at 00:38
@Ajeneral: highly unlikely... edit your question and post the actual code as a compilable unit. – chqrlie Dec 03 '15 at 00:43
@AJeneral I don't think `p/x` is the right output format for a uint64_t but I don't have gdb handy now to verify. – dxiv Dec 03 '15 at 00:45
You are correct! comment deleted. Why would `p/x` not be the right gdb command? gdb should know `temp` is a 64 bit unsigned int. – chqrlie Dec 03 '15 at 01:08
@chqrlie Right, I'll take that back. – dxiv Dec 03 '15 at 01:26

score 4 · Accepted Answer · answered Dec 03 '15 at 00:33

The size of uint32_t is 32 bits, not 28.

What happens here is that the most significant 4 bits are 0, and the leading zeros are not printed by gdb with p/x.

0xff00000 is the same as 0x0ff00000.

Use p/z thi to include the leading zeros when displaying. Have a look here: https://sourceware.org/gdb/onlinedocs/gdb/Output-Formats.html

uint32_t has 28 bits instead of 32 bits

2 Answers2