Roland Dreier wrote:
> > Because the target variable is an (int).
> If I were writing the code, I would leave the cast out. By assigning
> the value to an int variable, you get the same effect anyway, so the
> cast is redundant. And if you ever change the variable to a long, now
> you have to remember to delete the cast too. So I don't see any
> upside to having the cast.
> But it's just a minor style issue...
Some compilers can warn about implicit narrowing conversions, such as
one gets without the cast here when sizeof(long)>sizeof(int), though
none I know of due so by default. Enabling such warnings can be a good
way to look for 32 to 64-bit porting assumptions. However, if one has
too many false alarms, such as from intval=strtol(), then the real
problems get lost in the noise. As far as I am concerned, avoiding such
warnings are the only motivation for including the cast here. This may
or may not be sufficient motivation to include it, depending on the
IIRC the '-Wcheck' option to the Intel compilers is one way to get
warnings about implicit narrowing conversions, plus many other "legal
but potentially non-portable" code idioms - well beyond the scope of the
gcc '-Wall' option.
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900