Re: int to intXX_t conversion

On Fri, Feb 1, 2013 at 7:30 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/01/2013 10:20 AM, Kinkie wrote:
>> On Fri, Feb 1, 2013 at 6:08 PM, Alex Rousskov wrote:
>>> On 02/01/2013 04:01 AM, Kinkie wrote:
>>>> Is there any objection for me to entertain myself doing "int" ->
>>>> "intXX_t" and "unisgned int -> uintXX_t" conversions in the meanwhile?
>>>> This seems to be in line with c++11 changes, and should have no
>>>> adverse effects.
>
>>> What is the motivation behind this? Why intXX_t is better than int when
>>> we do not really care about the exact variable size?
>
>> It adds clarity, and a predictable cross-platform, cross-os and
>> cross-architecture memory layout.
>
> I am not sure int32_t adds "clarity" compared to "int" but it is
> difficult to argue about such vague concepts, and I will not in this case.

It adds consistent information: int32_t = signed integer, 32-bits
long. int = signed integer, currently somewhere between 16 and 64 bits
in size.

> Renaming "int" certainly has some pros. However, you have not listed any
> "cons". Are there really none? I think I can come up with a few:
>
> - There is currently no criteria which explicit int size to use. I think
> you have to develop and get them reviewed _before_ making these
> widespread changes. And we all would have to obey the final rules in the
> new code. This does add some overhead now and long-term.

I'd approach this just in the same way as bool-ification: as
progressively as possible. But yes: there would be conventions to
follow.
BTW: c++11 defines intXX_t as part of the core language; I believe
that to be an indication that the language will evolve in that
direction.

> - Saying "I did not think about the number of bits" is better than
> implying "I did think about the number of bits" when, in fact, I did
> not. A typical "int i = func();" code is a good example: If I see
> int32_t there, I would think that somebody carefully checked that func()
> can never return something bigger than that. Of course, you can
> carefully check every int in Squid, but that would take a lot of time
> that is better spent elsewhere.
>
> - Is it possible that on some platforms, int is not int32_t and is
> faster than int32_t? Now or in the foreseeable future? We know that on
> some platforms int_fast32_t is not int so perhaps the "opposite" can
> also be true? And if int is and will always be int32_t (e.g., for
> backward compatibility reasons), then perhaps spelling it differently is
> pointless?

According to a little bit of research I did, on all current unix,
unix-like and MS-Windows platforms, int == int32_t. In the past some
Unix platforms implemented int==int64_t, but apparently reverted
course.
In fact, blindly search & replacing and only thereafter think about
the opportunity of up- or downsizing some variables is probably the
most effective strategy.

One further pro I can think of, it provides further clues to automated
code checking tools about what we expect the needed size of a variable
to be, and to propagate this knowledge up the call chains, looking for
places where it may get truncated.

> - the visual distinction between signed and unsigned becomes less
> pronounced when you use [u]intXX_t names.
> - more ink for the more common "int" case
>
>
>> It is of course a matter of opinion in the end. It seems that I am
>> being more aggressive than the average with legacy code, especially
>> for "search and replace" things which don't require much brain power
>> such as this one.
>
> Is "int" really a "legacy", outdated concept not recommended for new
> code by C++ gurus? From my non-guru point of view, "int" is preferred
> when we do not want to think about exact bit sizes (whether that "not to
> think" decision is correct or not is a separate question, but the type
> accurately reflects that decision).

legacy and outdated, that's a bit of an extreme statement.
But (according to http://en.cppreference.com/w/cpp/types/integer )
c++11 defines 24 new integer types of various widths.

>> Besides StringNG, I'm trying to apply myself to side things such as
>> cleanup, c++-ification, STL-ification (in place of the plethora of
>> linked list implementations we have in place now), etc.
>
> Nothing wrong with that, of course, but I hope I can convince you to add
> bug fixing to the above list :-). I believe Amos mentioned 60+ v3.3 bugs
> waiting for a volunteer...

I'm still not good enough to produce meaningful results in these
areas, unfortunately.

--
    /kinkie