ANSI reference needed or debunked... 
Author Message
 ANSI reference needed or debunked...

Given this piece of code ...

  char k;

  k = 10;
  k = k + 1;

.. would you expect an ANSI-compliant compiler, with all warning
options enabled, to complain about anything in the above??

One that I'm using complains about loss of precision in k = k + 1; My
friendly Japanese supplier claims their compiler is ANSI-compliant.
Pointing out that none of the other ANSI-complient compilers I use shows
this behavior results in a statement that obviously none of these other
compilers truly are ANSI-compliant.

But, if I declare k an int and compile the same lines, the compiler
doesn't complain. If it worries about chars overflowing into ints, why
wouldn't it worry about ints overflowing into longs??

Any of you spec gurus care to comment on this? The only thing I know is
that I'm getting dang disgusted putting (char) casts all over the place.

--
---------------------------------------------------
best regards,




Sat, 08 May 2004 06:22:44 GMT  
 ANSI reference needed or debunked...


Quote:
>Given this piece of code ...
>  char k;
>  k = 10;
>  k = k + 1;
>.. would you expect an ANSI-compliant compiler, with all warning
>options enabled, to complain about anything in the above??

Someone will doubtless correct me but...

Firstly 1 is an int, so k is promoted to an int, and the addition
done. The result is then converted back into a char. There is loss of
precision since a char is typically smaller than an int.

Plus, in an arithmetic operation a char is promoted to an int anyway,
if the recent thread is recalled.

Of course, a smart compiler could realise that you were working with
chars, and avoid complaining. I've seen plenty that did complain.

Quote:
>But, if I declare k an int and compile the same lines, the compiler
>doesn't complain. If it worries about chars overflowing into ints, why
>wouldn't it worry about ints overflowing into longs??

Overflow is not the worry.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>



Sat, 08 May 2004 06:43:49 GMT  
 ANSI reference needed or debunked...

Quote:

> Given this piece of code ...

>   char k;

>   k = 10;
>   k = k + 1;

> .. would you expect an ANSI-compliant compiler, with all warning
> options enabled, to complain about anything in the above??

I'd not expect it, but it could.  The standard allows compiler
authors broad discretion in diagnostics.  There are certain
things for which diagnostics are required, but compilers may
issue diagnostic messages for anything.  The canonical example
around here is that the compiler may issue a diagnostic
complaining about the programmer's bad breath.

Quote:
> One that I'm using complains about loss of precision in k = k + 1; My
> friendly Japanese supplier claims their compiler is ANSI-compliant.

Additional warning messages are not a compliance issue.  They are
a quality-of-implementation issue.

Dann Corbit sent me some lint results on GNU libavl that gave
warning messages for the construct `char x = 0;' (or something
similar) complaining about loss of precision.  This is just
stupidity on the part of the lint author; ignore it.

Quote:
> Pointing out that none of the other ANSI-complient compilers I use shows
> this behavior results in a statement that obviously none of these other
> compilers truly are ANSI-compliant.

Did the vendor really say that?  That's wrong and stupid besides.
You must have talked to some underling; no author of an ANSI C
compliant compiler would ever say anything like that.

Quote:
> But, if I declare k an int and compile the same lines, the compiler
> doesn't complain. If it worries about chars overflowing into ints, why
> wouldn't it worry about ints overflowing into longs??

I think you're missing the point of this message.  It is warning
you that you are doing arithmetic on ints (`10' is an int) and
then storing the result into a char, which usually has a smaller
range.  This is not the same thing as doing arithmetic on ints
and then storing them into a int, because there is no possibility
for loss of precision on the assignment.

Quote:
> Any of you spec gurus care to comment on this? The only thing I know is
> that I'm getting dang disgusted putting (char) casts all over the place.

Turn off that warning then.
--
"I hope, some day, to learn to read.
 It seems to be even harder than writing."
--Richard Heathfield


Sat, 08 May 2004 06:48:36 GMT  
 ANSI reference needed or debunked...

Quote:

>Given this piece of code ...

>  char k;

>  k = 10;
>  k = k + 1;

>.. would you expect an ANSI-compliant compiler, with all warning
>options enabled, to complain about anything in the above??

Not required, but I'd want a warning.

Quote:

>One that I'm using complains about loss of precision in k = k + 1;

Right.  The literal one has type 'int' whose
full range of values is not guaranteed to
fit in a 'char'.

Quote:
> My
>friendly Japanese supplier claims their compiler is ANSI-compliant.

I don't think this is a compliance, but a QoI issue.

Quote:
>Pointing out that none of the other ANSI-complient compilers I use shows
>this behavior results in a statement that obviously none of these other
>compilers truly are ANSI-compliant.

Faulty reasoning. Think 'post-hoc ergo proptor hoc' :-)

Quote:
>But, if I declare k an int and compile the same lines, the compiler
>doesn't complain.

Right.  An 'int' fits in an 'int' :-)

Quote:
>If it worries about chars overflowing into ints, why
>wouldn't it worry about ints overflowing into longs??

Standard guranteees :  sizeof(long) >= sizeof(int)

But this is not an 'overflow' issue but a
'loss of precision' issue.

Quote:

>Any of you spec gurus care to comment on this? The only thing I know is
>that I'm getting dang disgusted putting (char) casts all over the place.

If the added value is always one, why not simply:

++k;

If the value will vary, how about creating
a (perhaps const) 'char' object with the desired
value, and adding that?

Or just use ints for the calculations, and
do the cast once for the eventual assignment.
(I'd check against e.g. 'CHAR_MAX' before
 the assignment though, just to be sure :-))

Another alternative would be to disable the
warning, but I tend to shy away from that.

-Mike



Sat, 08 May 2004 07:36:08 GMT  
 ANSI reference needed or debunked...

Quote:


>> Given this piece of code ...

>>   char k;

>>   k = 10;
>>   k = k + 1;

>> .. would you expect an ANSI-compliant compiler, with all warning
>> options enabled, to complain about anything in the above??

- cut -

Quote:
>> Pointing out that none of the other ANSI-complient compilers I use shows
>> this behavior results in a statement that obviously none of these other
>> compilers truly are ANSI-compliant.

>Did the vendor really say that?  That's wrong and stupid besides.
>You must have talked to some underling; no author of an ANSI C
>compliant compiler would ever say anything like that.

I've not gotten to the compiler gurus, just the support staff. But yes,
that's what was said.

Quote:
>> But, if I declare k an int and compile the same lines, the compiler
>> doesn't complain. If it worries about chars overflowing into ints, why
>> wouldn't it worry about ints overflowing into longs??

>I think you're missing the point of this message.  It is warning
>you that you are doing arithmetic on ints (`10' is an int) and
>then storing the result into a char, which usually has a smaller
>range.  This is not the same thing as doing arithmetic on ints
>and then storing them into a int, because there is no possibility
>for loss of precision on the assignment.

Yes, I agree that 10 is an int, so that's a point well-taken. But if the
compiler will allow assignment of a small-valued int to a char, it
doesn't seem to be consistant to complain about an addition involving a
char and another small-valued constant. If it decides the first case is
acceptable, it should be able to make the same decision in the second
case. I have observed many other compilers that do, as you point out.

I'm not sure that the compiler writers aren't trying to protect against
overflow. By the preceeding logic, the following should be acceptable:

char a = 10;
char b = 10;

a = a + (char)1;
a = a + b;

i.e. (char) = (char) + (char); - but the compiler generates the same
loss of precision message for both assignments. Which is why I made the
comment about overflow. But this situation wasn't shown in the first
example I gave.

Quote:

>Turn off that warning then.

Yeah, but that warning does have legitimate use, at least for the way I
code. For every umpty-hundred (char) complaints, it finds one genuine
farkle.

Thx. for the quick reply.

--
---------------------------------------------------
best regards,




Sat, 08 May 2004 07:48:19 GMT  
 ANSI reference needed or debunked...

Quote:

> I'm not sure that the compiler writers aren't trying to protect against
> overflow. By the preceeding logic, the following should be acceptable:

> char a = 10;
> char b = 10;

> a = a + (char)1;
> a = a + b;

> i.e. (char) = (char) + (char); - but the compiler generates the same
> loss of precision message for both assignments. Which is why I made the
> comment about overflow. But this situation wasn't shown in the first
> example I gave.

No, this is the same thing.  The sum of two chars is an int (or
an unsigned int).  So again there is a narrowing conversion to
store the result in a char.


Sat, 08 May 2004 07:53:42 GMT  
 ANSI reference needed or debunked...

[...]

    FW> Yes, I agree that 10 is an int, so that's a point well-taken. But if the
    FW> compiler will allow assignment of a small-valued int to a char, it
    FW> doesn't seem to be consistant to complain about an addition involving a
    FW> char and another small-valued constant. If it decides the first case is
    FW> acceptable, it should be able to make the same decision in the second
    FW> case. I have observed many other compilers that do, as you point out.

During the compile, the compiler knows that 10 will fit into a char.

However, when it does the addition, it has no way of knowing that
(k+1) will fit into a char - if k == CHAR_MAX, then how would you put
k+1 into the char?

[...]

Cheers,
Kevin

--
He that breaks a thing to find out what it is has left the path of
wisdom                                         -- Gandalf the Grey



Sat, 08 May 2004 08:05:17 GMT  
 ANSI reference needed or debunked...

Quote:

>> i.e. (char) = (char) + (char); - but the compiler generates the same
>> loss of precision message for both assignments. Which is why I made the
>> comment about overflow. But this situation wasn't shown in the first
>> example I gave.

>No, this is the same thing.  The sum of two chars is an int (or
>an unsigned int).  So again there is a narrowing conversion to
>store the result in a char.

The sum of two chars is an int, by the ANSI spec, or from knowledge that
the sum may overflow a char, depending on the values? If from the spec,
OK, end of issue. If the latter, then consistancy would dictate that:

(int) = (int) + (int) should also cause a complaint (which it does not)
since adding two ints could also overflow an int.

--
---------------------------------------------------
best regards,




Sat, 08 May 2004 10:13:46 GMT  
 ANSI reference needed or debunked...

Quote:

>Plus, in an arithmetic operation a char is promoted to an int anyway,
>if the recent thread is recalled.

I did not see that thread, but given that promotion occurs, what you say
makes sense. And given that ints are not promoted to longs, it also
makes sense that similar constructs on ints do not cause complaints.

Quote:
>Of course, a smart compiler could realise that you were working with
>chars, and avoid complaining. I've seen plenty that did complain.

Amen...  I've not seen another that complained.

Thx, all who responded.

--
---------------------------------------------------
best regards,




Sat, 08 May 2004 10:22:35 GMT  
 ANSI reference needed or debunked...

Quote:


> >Given this piece of code ...

> >  char k;

> >  k = 10;
> >  k = k + 1;

> >.. would you expect an ANSI-compliant compiler, with all warning
> >options enabled, to complain about anything in the above??

> Not required, but I'd want a warning.

Not really. That's a stupid warning.

Quote:
> >One that I'm using complains about loss of precision in k = k + 1;

> Right.  The literal one has type 'int' whose
> full range of values is not guaranteed to
> fit in a 'char'.

Yes, but a character literal such as 'x' is also of type int. In fact, a char
plus another char also becomes an int because of the standard integral
promotions.

Quote:
> If the value will vary, how about creating
> a (perhaps const) 'char' object with the desired
> value, and adding that?

I think you spend too much time using a C++ compiler. :)

Any arithmetic expressions involving types smaller than ints are promoted to
ints, so your suggestion won't help.

Quote:
> Another alternative would be to disable the
> warning, but I tend to shy away from that.

For stupid warnings like this I have no problems with disabling warnings. The
next thing you know the compiler will complain about "forgetting" to cast the
return value of malloc(). :)

Bart.



Sat, 08 May 2004 10:34:31 GMT  
 ANSI reference needed or debunked...

Quote:

> >> i.e. (char) = (char) + (char); - but the compiler generates the same
> >> loss of precision message for both assignments. Which is why I made the
> >> comment about overflow. But this situation wasn't shown in the first
> >> example I gave.

> >No, this is the same thing.  The sum of two chars is an int (or
> >an unsigned int).  So again there is a narrowing conversion to
> >store the result in a char.

> The sum of two chars is an int, by the ANSI spec, or from knowledge that
> the sum may overflow a char, depending on the values? If from the spec,
> OK, end of issue. If the latter, then consistancy would dictate that:

It's from the ANSI standard.

ISO/IEC 9899:1999
6.3.1.1 paragraph 2:

2 The following may be used in an expression wherever an int or unsigned
  int may be used:

  An object or expression with an integer type whose integer conversion
    rank is less than the rank of int and unsigned int.

  A bit-field of type _Bool, int, signed int, or unsigned int.

  If an int can represent all values of the original type, the value is
  converted to an int; otherwise, it is converted to an unsigned int.
  These are called the integer promotions. All other types are unchanged by
  the integer promotions.

Bart.



Sat, 08 May 2004 10:42:46 GMT  
 ANSI reference needed or debunked...

Quote:


> >> i.e. (char) = (char) + (char); - but the compiler generates the same
> >> loss of precision message for both assignments. Which is why I made the
> >> comment about overflow. But this situation wasn't shown in the first
> >> example I gave.

> >No, this is the same thing.  The sum of two chars is an int (or
> >an unsigned int).  So again there is a narrowing conversion to
> >store the result in a char.

> The sum of two chars is an int, by the ANSI spec, or from knowledge that
> the sum may overflow a char, depending on the values?

It's required by the standard.  

Quote:
> (int) = (int) + (int) should also cause a complaint (which it does not)
> since adding two ints could also overflow an int.

That's a different issue.  By that logic every single standard
arithmetic operation with binary +, binary or unary -, or *
should provoke a warning.  I suppose you'd still let us get away
with division?  Or should that, by your logic, provoke a warning
that the divisor may be zero?
--
"It wouldn't be a new C standard if it didn't give a
 new meaning to the word `static'."
--Peter Seebach on C99


Sat, 08 May 2004 11:23:05 GMT  
 ANSI reference needed or debunked...


...

Quote:
>That's a different issue.  By that logic every single standard
>arithmetic operation with binary +, binary or unary -, or *
>should provoke a warning.  I suppose you'd still let us get away
>with division?  Or should that, by your logic, provoke a warning
>that the divisor may be zero?

INT_MIN/-1 could overflow. :-)

--
-----------------------------------------


-----------------------------------------



Sat, 08 May 2004 19:29:19 GMT  
 ANSI reference needed or debunked...


Quote:


>>Given this piece of code ...

>>  char k;

>>  k = 10;
>>  k = k + 1;

>>.. would you expect an ANSI-compliant compiler, with all warning
>>options enabled, to complain about anything in the above??

>Not required, but I'd want a warning.

It is a quality of impementation issue. Any compiler that does complain
about this is being excessively dumb which suggests to me that quality is
lacking at least in some areas.

Quote:
>>One that I'm using complains about loss of precision in k = k + 1;

>Right.  The literal one has type 'int' whose
>full range of values is not guaranteed to
>fit in a 'char'.

Although of course this one does and the compiler can determine trivially
that in this particualr case the result is representable as a char.

Quote:
>> My
>>friendly Japanese supplier claims their compiler is ANSI-compliant.

>I don't think this is a compliance, but a QoI issue.

>>Pointing out that none of the other ANSI-complient compilers I use shows
>>this behavior results in a statement that obviously none of these other
>>compilers truly are ANSI-compliant.

>Faulty reasoning. Think 'post-hoc ergo proptor hoc' :-)

Right, this person doesn't know what he is talking about.

Quote:
>>But, if I declare k an int and compile the same lines, the compiler
>>doesn't complain.

>Right.  An 'int' fits in an 'int' :-)

>>If it worries about chars overflowing into ints, why
>>wouldn't it worry about ints overflowing into longs??

>Standard guranteees :  sizeof(long) >= sizeof(int)

No, the standard doesn't guarantee this. However it does guarantee that
LONG_MAX>=INT_MAX and LONG_MIN<=INT_MIN.

Quote:
>But this is not an 'overflow' issue but a
>'loss of precision' issue.

In both cases the problem is when the resulting value cannot be
represented by the resulting type.

Quote:
>>Any of you spec gurus care to comment on this? The only thing I know is
>>that I'm getting dang disgusted putting (char) casts all over the place.

>If the added value is always one, why not simply:

>++k;

>If the value will vary, how about creating
>a (perhaps const) 'char' object with the desired
>value, and adding that?

This probably won't help because char operands will get promoted to int
(possibly unsigned int but unlikely) before the addition is performed.

Quote:
>Or just use ints for the calculations, and
>do the cast once for the eventual assignment.

This is a good point. Why is char being used for an auxilliary variable
like this?

Quote:
>(I'd check against e.g. 'CHAR_MAX' before
> the assignment though, just to be sure :-))

>Another alternative would be to disable the
>warning, but I tend to shy away from that.

If it is possible it may be the best cours of action. If char is a sensible
choice of variable type here then messing up good code to get around
poor tools is not a good thing to do.

--
-----------------------------------------


-----------------------------------------



Sat, 08 May 2004 19:32:48 GMT  
 ANSI reference needed or debunked...


Quote:

>[...]

>    FW> Yes, I agree that 10 is an int, so that's a point well-taken. But if
> the
>    FW> compiler will allow assignment of a small-valued int to a char, it
>    FW> doesn't seem to be consistant to complain about an addition involving a >    FW> char and another small-valued constant. If it decides the first case is >    FW> acceptable, it should be able to make the same decision in the second
>    FW> case. I have observed many other compilers that do, as you point out.

>During the compile, the compiler knows that 10 will fit into a char.

Right, it probably checks the value itself when a constant expression
is being converted to char.

Quote:
>However, when it does the addition, it has no way of knowing that
>(k+1) will fit into a char - if k == CHAR_MAX, then how would you put
>k+1 into the char?

k+1 isn't a constant expression in this case but it would be trivial for
the compiler to determine that the value of k+1 is 11 which is always
representable as a char.

--
-----------------------------------------


-----------------------------------------



Sat, 08 May 2004 19:47:24 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Need: ANSI cxref (cross-reference utility)

2. ANNOUNCE: formatted copies of the GDB and ANSI C quick reference cards

3. ANNOUNCE: formatted copies of the GDB and ANSI C quick reference cards

4. ANSI C Library reference manual online?

5. ANSI C99 reference book

6. ANSI C99 reference book

7. ansi c reference manual

8. ANSI C Library Pocket Reference

9. ANSI C -- static forward references

10. ANSI C / C++ Reference

11. Advice on book(s) on ANSI C ? ( reference )

12. Ansi C function reference card?

 

 
Powered by phpBB® Forum Software