T
those who know me have no need of my name
in comp.lang.c i read:
what warning is emitted? `strict' type mismatch is the the only thing that
comes to mind. not an issue in the language since char is an integer and
any arithmetic using char must be promoted to at least int, but it is
checked by many lints, some [pieces] of which have found their way into
compilers. if this is the case it could also be quelled with: a +=
(char)4, though the slight change in semantics (the arithmetic remains the
same) from yours vs the continued presence of a cast makes it hardly worth
using as a replacement. any other method of supplying a char instead of an
int would likely be just as ugly:
#define CHAR_C(c) (char)c
...
a += CHAR_C(4);
there is a potential issue worth some consideration, so perhaps it's not a
terrible warning. signed integer overflow has implementation defined
behavior, as is the type of `plain' char. so while '0'+4 cannot be outside
the range of char, the result of a+4 where a has an arbitrary value might.
any implementation change (different platform, different compiler, updated
compiler, or maybe just different options used) might produce a result you
didn't expect. on many platforms today this doesn't happen, but it can on
some (typically older systems) and for all we know another such system will
become extremely popular (read: you need to port to it) tomorrow.
It also complains about things like:
char a = '0';
...
a += 4; /* a = (char)(a + 4); will "fix" the warning */
/* so will turning down the warning level */
what warning is emitted? `strict' type mismatch is the the only thing that
comes to mind. not an issue in the language since char is an integer and
any arithmetic using char must be promoted to at least int, but it is
checked by many lints, some [pieces] of which have found their way into
compilers. if this is the case it could also be quelled with: a +=
(char)4, though the slight change in semantics (the arithmetic remains the
same) from yours vs the continued presence of a cast makes it hardly worth
using as a replacement. any other method of supplying a char instead of an
int would likely be just as ugly:
#define CHAR_C(c) (char)c
...
a += CHAR_C(4);
there is a potential issue worth some consideration, so perhaps it's not a
terrible warning. signed integer overflow has implementation defined
behavior, as is the type of `plain' char. so while '0'+4 cannot be outside
the range of char, the result of a+4 where a has an arbitrary value might.
any implementation change (different platform, different compiler, updated
compiler, or maybe just different options used) might produce a result you
didn't expect. on many platforms today this doesn't happen, but it can on
some (typically older systems) and for all we know another such system will
become extremely popular (read: you need to port to it) tomorrow.