Quantcast
Channel: Raspberry Pi Forums
Viewing all articles
Browse latest Browse all 3843

SDK • Re: troubletrouble defining a macro to replace a zero argument fn call: micros()

$
0
0
Am I making a dumb mistake? shouldn't %d handle a uint64_t?
No. And that's the cause of your problem in the previous post too: uint64_t is not the same size as 'long int' (which is only 32 bits on this platform).

On this platform, 'int' and 'long int' are the same size (32 bits), and 'long long int' is 64-bit.

So you need %lld or in fact, since it's unsigned, you should be using %llu

This printf stuff is a mess, unfortunately. It's nice that nowadays you have the explicit-size types for use when you care about the number of bits (which is a lot of the time in embedded work), and the traditional types to 'just give me the most efficient size of integer on this platform' for things like loop counters - that's good for portable code. But there aren't matching printf specifiers, so you can't make those strings portable.

The official way appears to be:

Code:

#include <inttypes.h>{uint32_t foo = 123;uint64_t bar = 678;printf("foo is %" PRIu32 " bar is " PRId64 "\n", foo, bar);}
which works but is incredibly ugly and hard to read.

For debugging printfs where I don't care about the full range (I can't visually parse decimal values above 4 billion anyhow), I often use this instead which is still voluminous but easy to read.

Code:

printf("foo %u bar %d\n", (unsigned) foo, (int)bar);
It's important to do something, even for the 32-bit ones that would 'just work', as the slew of compiler warnings otherwise distract you from seeing warnings that actually matter.

Statistics: Posted by arg001 — Fri Nov 15, 2024 11:11 am



Viewing all articles
Browse latest Browse all 3843

Trending Articles