Hi all,

First some context; I started in a situation where I had a typedef uint in a forced include file, meaning I used uint throughout my whole codebase, when I wanted a uint32t. But I decided to get rid of them. So what I did is replace them all by either unsigned int or uint32_t in certain cases.

Now the challenge is, the compiler won’t tell the difference between them, so it won’t notify me of any mistakes in say function interface in a header versus implementation in the cpp. Same for class member vars and potential casts.

My question is, is there a way to identify any faults in this whole conversion? I thought of temporary changing the uint32t typedef in cstdint, but that feels a bit risky.

Any ideas?

I remember talks about you changing it on chat - so basically what the current state is that you may have instances where you use unsigned int in declaration and uint32_t in definition (or vice-versa)…

Your proposed change may work, but you will hit problems when editing either stdint.h or cstdint (keep in mind, BOTH of these define it). I personally would refrain from editing stdlib or libc headers (as it may bury you in warnings & errors not relevant to the code you want to update).

Doing that manually (especially in Visual Studio - where you can go to declaration/definition) might be preferred.

If the code base is huge you could write a python script (or maybe a regex would be enough … not sure though?) to match methods by name and report you where they differ. No automated solution though, you'd have to write it by hand.

You might be able to avoid gratuitous mass changes and ensure peaceful coexistence of headers with tests

assert(sizeof(uint)==sizeof(uint32_t)); 
assert(sizeof(uint32t)==sizeof(uint32_t));

and macros

#ifdef uint
	assert(sizeof(uint)==sizeof(uint32_t)); 
#else
	#define uint uint32_t
#endif

and typedefs

typedef uint uint32;

in a small include file of your own, to be placed after library includes in order to “normalize” the set of available types in your own code.