Just want to know why

[those who know me have no need of my name]

in comp.lang.c i read:

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.

 

[Christian Bau]

in comp.lang.c i read:

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.

In the case of '0', '1' to '9', the C Standard explicitely guarantees
that they are consecutive values, so '0' + 4 will produce '4' on every
single C implementation. This is different from the letters, for example
'a' + 4 could be anything according to the C Standard, even though it is
'e' if your compiler uses ASCII or a superset of ASCII.

 

[Peter Pichler]

in comp.lang.c i read:


what warning is emitted?

Something along the lines of "conversion from int to char: possible loss of
data". I don't remember the warning number and cannot post from work, only
read.

#define CHAR_C(c) (char)c
...
a += CHAR_C(4);

Why would you think this would make a difference? The conversion happens in
the assignment, not on the right side of '='.

there is a potential issue worth some consideration, so perhaps it's not a
terrible warning.

I know, that's why we eventually decided to put up with it. Since
warningless compilation is a company policy, and since we use a multitude of
compilers in the company, solving each case individually with a cast seemed
the simplest solution. It is ugly and unnecessary, but it does the job.

As we are OT already (hopefully not too much) - this is not the worst case.
One of the compilers we use is VAX C, a pre-ANSI compiler that undersdands
a=-1 as a-=1 and does not understand # in macros. So the code is cluttered
with things like:

#if !defined VAX_C
#define something(x) #x
#else
#define something(x) "x"
#endif

Strange? Indeed!

Peter

 

[CBFalconer]

Something along the lines of "conversion from int to char:
possible loss of data". I don't remember the warning number and
cannot post from work, only read.


Why would you think this would make a difference? The conversion
happens in the assignment, not on the right side of '='.

The simple solution is to make a an int to start with. Then it
can even hold EOF. Poof go the warnings.

I know, that's why we eventually decided to put up with it. Since
warningless compilation is a company policy, and since we use a
multitude of compilers in the company, solving each case
individually with a cast seemed the simplest solution. It is ugly
and unnecessary, but it does the job.

As we are OT already (hopefully not too much) - this is not the
worst case. One of the compilers we use is VAX C, a pre-ANSI
compiler that undersdands a=-1 as a-=1 and does not understand

Foolishness. Blanks are in fairly good supply, and are even
legal. Why not simply write:

a = -1;

# in macros. So the code is cluttered with things like:

#if !defined VAX_C
#define something(x) #x
#else
#define something(x) "x"
#endif

and I would closely examine the usage of something() with a view
to eliminating it. I can't believe that is critical. I can
believe that someone sometime wrote sloppy code. S/he was
probably even proud of it.

 

[Dan Pop]

As we are OT already (hopefully not too much) - this is not the worst case.
One of the compilers we use is VAX C, a pre-ANSI compiler that undersdands
a=-1 as a-=1 and does not understand # in macros. So the code is cluttered
with things like:

#if !defined VAX_C
#define something(x) #x
#else
#define something(x) "x"
#endif

Strange? Indeed!

The strangest part is the option NOT to upgrade to a more recent version
of VAX C, that implements ANSI C. The one you're using should not grok
function prototypes either.

Of course, now it may be too late for such an upgrade (dunno if HP bothers
supporting anything related to VAX/VMS), but 10 years ago (when VAX/VMS
was still alive and kicking and owned by DEC) it was, by far, the most
sensible way to go.

Dan

 

[Ed Vogel]

The strangest part is the option NOT to upgrade to a more recent version
of VAX C, that implements ANSI C. The one you're using should not grok
function prototypes either.

The more recent version of VAX C was DEC C (later renamed to Compaq C).

Of course, now it may be too late for such an upgrade (dunno if HP bothers
supporting anything related to VAX/VMS), but 10 years ago (when VAX/VMS
was still alive and kicking and owned by DEC) it was, by far, the most
sensible way to go.

Still supported and available.
See http://h71000.www7.hp.com/commercial/c/c_index.html

The VAX version of the compiler does not have all the features of the
Alpha compiler (such as array bounds checking noted in another string),
but it is still available.

Ed Vogel
HP (Compaq/DEC) C Engineering.

 

[those who know me have no need of my name]

in comp.lang.c i read:

those who know me have no need of my name <[email protected]>
wrote:

In the case of '0', '1' to '9', the C Standard explicitely guarantees
that they are consecutive values, so '0' + 4 will produce '4' on every
single C implementation.

indeed. but that wasn't the thrust.

char a = '0';
/*
a may be set to some other value here
*/
a += 4;

if a is still '0' everything is good, the result is '4' as you have explained
for the reason you explained. but if a is signed and has a value of CHAR_MAX
- 3 or higher then the resulting integer value is outside the range of char
and the assignment has implementation defined behavior.

in fact INT_MAX can be the same as CHAR_MAX in which case the arithmetic
also has implementation defined behavior.