On: My int is too big

[caf]

In C code that we write, we have a rule that every use of plain 'int' must be justified - it's a "code smell". Most places where 'int' is used should be replaced with 'size_t' (if used as an index to an array), or a C99 int32_t etc.

I completely disagree (except with the size_t bit - I agree with that). In my view, it's usages of int32_t and similar that should be justified: why you do you need exactly 32 bits and 2s complement representation - why does at least 32 bits and unspecific representation not suffice?

[cronjobber → caf]

> why does at least 32 bits and unspecific representation not suffice?

Because that doesn't help you. Static reasoning becomes harder. Dynamic checks (pretending the exact size is unknown) are possible but .. the exact size is statically known (just not to the programmer). It is a waste.

The sentiment is right, but the solution is metaprogramming, not unhelpfully underspecified types.

[rwmj → caf]

I didn't say that every use of 'int' should be replaced by 'int32_t'. In fact most uses are replaced with 'size_t' because you're counting something and should be worrying about overflow/wraparound.

Also I didn't say that you should never use 'int'. Yesterday I had to use 'int' because the sscanf %n pattern requires it, ironically an example of exactly what I'm talking about -- it won't be able to handle strings longer than ~2^31 bytes. But in this case the string comes from a place where we know it cannot exceed this limit, so we're OK.

[Too → caf]

Depends on your application I would say, if you build a database you want it to be able to store more automatically when hardware gets better. If you store physical measurements from sensors you know for sure that this sensor can only give values within a certain range, there you want to ensure you have the range required and it's also redundant to use a larger variable. I would still prefer int_least32 over just int though to be more explicit.