Is there a warning when using the wrong types that do not have the same underlying type on all systems?

Often, one sees code like this:

string s;
size_t length_of_string = s.size();

Although this is correct, and should not bite you in the buttocks on any common implemenetation, it’s not pedantically correct and fully portable. The return type of string::size is by definition string::size_type, and although the common existing implementations use size_t, these two don’t have to be the same type, and could result in unexpected weirdness.
Is there any warning available (or uberhaupt implementable) in Clang that checks these kinds of implementation-dependent conversions, and perhaps suggest the type better suited (or a static_cast to the user’s type)?

I understand this is pure pedantry and of little practical use (especially the string::size() case), but I would figure there could be larger bugs exposed in a more general case where there is an unnecessary implicit conversion. (although that word would mean these shouldn’t be warned for at all, as it’s a predefined language feature).

Thanks!

Ruben

As you said there is no problem when these types are the same (string::size_type being a typedef to size_t). And in case they do differ, the compiler would give a warning assuming the conversion is potentially dangerous (int x = s.size())?

So I guess everything already works as expected? I just can’t see the benefit of your proposal. I personally hate seeing code like string::size_type and map::value_type, even though it’s more correct it just seems like more verbosity in the most verbose language ever :slight_smile: