Programming

And that makes your code non-portable. The C standard specifies

Code:

int main( int, char ** )

Note that 16, 32, or 64 bit integral values are not specified - how many bits are in an "int" is an implementation-specific detail.


If you use

Code:

int32_t main( int32_t, char **)

you'll find another source of SEGVs if you specify "int32_t" on any architecture where an integer is implemented as anything other than 32 bits. In that case, the argc argument to main() will be placed on the stack as 64-bit value, say, and your code will pull it off as 32-bit value. Then value of argc your code sees will be way off, and the argv pointer value your code uses will most likely point off into la-la land.

Then I think using size_t or ssize_t would make codes even more portable rather than declaring as int or unsigned int.

Why would you even want to use size_t or ssize_t in main()? It's defined as int. Using fancy defined types isn't the point -- the point of these types isn't to use them everywhere, the point is to use them when you need them. ssize_t is defined to match certain library and system calls, but main() is not among them. You may not realize it, but main() is called by a library which assumes main() is int main(int argc, char *argv[]). Use anything else, and you're lying to that library, feeding it the wrong kind of function. It may work if you're lucky on some platforms where size_t and the like are the right size anyway, but change platforms and it could mess up extravagantly. Segmentation faults, and the like. I've experienced this personally.

In other words -- I think you missed the point of my post.

Are you doing calculations with intentional overflow, bit manipultion, or other such things where -- if your integers aren't 32/64/whatever bits, your code is guaranteed to not work?

These are the sort of circumstances int32_t, uint64_t, et all are designed for.

If you don't actually need 32 bits and nothing but 32 bits, don't demand it.

And never, ever, ever use weird types in things already defined as ordinary types, like in main(). If it works at all it's pure coincidence, and can bite you hard when you go to a radically different architecture or bit width(as I've experienced personally many times. Someone gets overenthusiastic and declares a function as size_t then goes ahead and uses it as int instead somewhere else, causing extremely hard-to-track bugs when parameters getting passed into the function get mangled...)

Yes, I would agree to keep things simple and in my future programming tasks I shall take care of this. I had never thought things could be so serious because I have never experienced it. But now it gives me a chance to experiment things on different machines and architectures.