Re: int to intXX_t conversion

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.

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.

- 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?

- 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).

> 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...

Thank you,

Alex.
Received on Fri Feb 01 2013 - 18:31:03 MST