warning while making cast

[vippstar]

Hello,

given a simple code:

#include <math.h>
long hyp(long height, long base)
{
return sqrt(height * height + base * base);

}

int main(void)
{
long h = hyp(10, 20);
return 0;

}

I compile this on Debian 4.0 (gcc (GCC) 4.1.2 20061115 (prerelease) (Debian
4.1.1-21)):
#gcc -ansi -pedantic -W -Wall -lm hyp.c

As I understand, according to standard sqrt returns double, but we assign
result to long, resulting in information loss. Nevertheless I get no
warning, why is it so?

Hope it's strictly C related question.

The return value of sqrt is implicity converted to long.
6.3.1.4 --
When a ï¬nite value of real floating type is converted to an integer
type other than _Bool,
the fractional part is discarded (i.e., the value is truncated toward
zero). If the value of
the integral part cannot be represented by the integer type, the
behavior is undeï¬ned.

 

[Richard Tobin]

As I understand, according to standard sqrt returns double, but we assign
result to long, resulting in information loss. Nevertheless I get no
warning, why is it so?

Compilers aren't required to warn you about information loss. I would
certainly find it annoying if a compiler did that by default.

I would have expected gcc to warn about it if you specified -Wconversion,
but it doesn't seem to, so you could report that as a bug.

-- Richard

 

[blockstack]

Hello, Richard!
You wrote  on 5 Jun 2008 11:41:34 GMT:

 RT> Compilers aren't required to warn you about information loss.  I would
 RT> certainly find it annoying if a compiler did that by default.

By default no, but -Wextra is supposed to report about loss of precision as
well. It does not in this case at least. Perhaps this is more GCC relevant
topic.

 RT> I would have expected gcc to warn about it if you specified
 RT> -Wconversion, but it doesn't seem to, so you could report that as a
 RT> bug.

Compiling with -Wconversion invokes this warning:
warning: passing argument 1 of 'sqrt' as floating rather than integer due to
prototype

But nothing about result of function.

With best regards, Roman Mashak.  E-mail: (e-mail address removed)

try using -Wtraditional-conversion

 

[vippstar]

Hello, (e-mail address removed)!
You wrote on Thu, 5 Jun 2008 04:27:18 -0700 (PDT):

v> The return value of sqrt is implicity converted to long.
In my understanding implicit conversion is a promotion of types, i.e.
without loss of bits. For instance, float to double

v> 6.3.1.4 --
v> When a ?nite value of real ?oating type is converted to an integer
v> type other than _Bool,
v> the fractional part is discarded (i.e., the value is truncated toward
v> zero). If the value of
v> the integral part cannot be represented by the integer type, the
v> behavior is unde?ned.
Is this excerpt from C99 standard? I compiled the snippet with -ansi, which
is C90 conformant.

Yes it is, but I believe the same rules apply for C90.

 

[Keith Thompson]

Hello, (e-mail address removed)!
You wrote on Thu, 5 Jun 2008 04:27:18 -0700 (PDT):

v> The return value of sqrt is implicity converted to long.

In my understanding implicit conversion is a promotion of types, i.e.
without loss of bits. For instance, float to double

[...]

I'm afraid your understanding is incorrect.

The promotions that occur for operands of most operators are designed
not to lose information (at least in most cases(?)), but those aren't
the only implicit conversions that can occur. In an assignment or
equivalent (initialization, parameter passing), any arithmetic type
can be implicitly converted to any other arithmetic type. You can
even assign a long double to a char. No diagnostic is required,
though compilers are free to print warnings if they choose.

 

[Roman Mashak]

Hello,

given a simple code:

#include <math.h>
long hyp(long height, long base)
{
return sqrt(height * height + base * base);
}

int main(void)
{
long h = hyp(10, 20);
return 0;
}

I compile this on Debian 4.0 (gcc (GCC) 4.1.2 20061115 (prerelease) (Debian
4.1.1-21)):
#gcc -ansi -pedantic -W -Wall -lm hyp.c

As I understand, according to standard sqrt returns double, but we assign
result to long, resulting in information loss. Nevertheless I get no
warning, why is it so?

Hope it's strictly C related question.

With best regards, Roman Mashak.

 

[Roman Mashak]

Hello, (e-mail address removed)!
You wrote on Thu, 5 Jun 2008 04:27:18 -0700 (PDT):

v> The return value of sqrt is implicity converted to long.
In my understanding implicit conversion is a promotion of types, i.e.
without loss of bits. For instance, float to double

v> 6.3.1.4 --
v> When a ?nite value of real ?oating type is converted to an integer
v> type other than _Bool,
v> the fractional part is discarded (i.e., the value is truncated toward
v> zero). If the value of
v> the integral part cannot be represented by the integer type, the
v> behavior is unde?ned.
Is this excerpt from C99 standard? I compiled the snippet with -ansi, which
is C90 conformant.

With best regards, Roman Mashak. E-mail: (e-mail address removed)

 

[Roman Mashak]

Hello, Richard!
You wrote on 5 Jun 2008 11:41:34 GMT:

RT> Compilers aren't required to warn you about information loss. I would
RT> certainly find it annoying if a compiler did that by default.

By default no, but -Wextra is supposed to report about loss of precision as
well. It does not in this case at least. Perhaps this is more GCC relevant
topic.

RT> I would have expected gcc to warn about it if you specified
RT> -Wconversion, but it doesn't seem to, so you could report that as a
RT> bug.

Compiling with -Wconversion invokes this warning:
warning: passing argument 1 of 'sqrt' as floating rather than integer due to
prototype

But nothing about result of function.

With best regards, Roman Mashak. E-mail: (e-mail address removed)

 

[akbar]

Hello,

given a simple code:

#include <math.h>
long hyp(long height, long base)
{
    return sqrt(height * height + base * base);

}

int main(void)
{
   long h = hyp(10, 20);
   return 0;

}

I compile this on Debian 4.0 (gcc (GCC) 4.1.2 20061115 (prerelease) (Debian
4.1.1-21)):
#gcc -ansi -pedantic -W -Wall -lm hyp.c

As I understand, according to standard sqrt returns double,  but we assign
result to long, resulting in information loss. Nevertheless I get no
warning,  why is it so?

Hope it's strictly C related question.

With best regards, Roman Mashak.

Hello Roman,

Yes, GCC doesn't show any warning as such even after trying with
multiple warning options.

Please try using Splint tool, it should definetly show return-type-
mismatch warning.

Thanks
Akbar

 

[Richard Bos]

On Thu, 5 Jun 2008 04:27:18 -0700 (PDT), (e-mail address removed) wrote in



I assume you're using Foxit for a PDF reader. Surely you've noticed
that it does not handle the single glyph combining the letter
combination "fi" in some documents, including the C standard.

It's not necessarily Foxit. I've seen the same with pastes from Acrobat
Reader, into a newsreader which does not recognise those ligatures.

I always do a search and replace of '?' with "fi" before I post a
paste from Foxit.

You have fioating point types?

Richard

 

[jaysome]

Hello,

given a simple code:

#include <math.h>
long hyp(long height, long base)
{
return sqrt(height * height + base * base);
}

int main(void)
{
long h = hyp(10, 20);
return 0;
}

I compile this on Debian 4.0 (gcc (GCC) 4.1.2 20061115 (prerelease) (Debian
4.1.1-21)):
#gcc -ansi -pedantic -W -Wall -lm hyp.c

As I understand, according to standard sqrt returns double, but we assign
result to long, resulting in information loss. Nevertheless I get no
warning, why is it so?

Hope it's strictly C related question.

With best regards, Roman Mashak.

The Microsoft Visual C++ 6.0 compiler (circa 1998) gives these
warnings:

Compiling...
hyp.c
hyp.c(4) : warning C4244: 'return' : conversion from 'double ' to
'long ', possible loss of data
hyp.c(9) : warning C4189: 'h' : local variable is initialized but not
referenced

hyp.obj - 0 error(s), 2 warning(s)

PC-lint gives these warnings:

PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software
1985-2006

--- Module: hyp.c (C)
_
return sqrt(height * height + base * base);
hyp.c(4) : Info 747: Significant prototype coercion (arg. no. 1) long
to double
hyp.c(4) : Info 790: Suspicious truncation, integral to float
hyp.c(4) : Warning 524: Loss of precision (return) (double to long)
_
}
hyp.c(11) : Warning 529: Symbol 'h' (line 9) not subsequently
referenced
hyp.c(9) : Info 830: Location cited in prior message

--- Global Wrap-up

Note 900: Successful completion, 5 messages produced
Tool returned code: 0

If you want warnings, you could:

(1) Use Windows and compile with VC++ 6.0 (circa 1998) or even give
the free VC++ Express Editions a try.
(2) Use PC-lint on your code.

 

[Richard Tobin]

I assume you're using Foxit for a PDF reader. Surely you've noticed
that it does not handle the single glyph combining the letter
combination "fi" in some documents, including the C standard.

It has handled it corrrectly. The post you were replying to contained
the unicode characters for the ligatures, encoded in UTF-8. The
problem is presumably that your newsreader (like mine) does not
display UTF-8 correctly.

-- Richard

 

[lawrence.jones]

I always do a search and replace of '?' with "fi" before I post a
paste from Foxit.

Unfortunately, the ? might actually be supposed to be "fl" instead. (Or
potentially lots of other things, too, but the C Standard should only
have fi and fl ligatures.)

-- Larry Jones

Good gravy, whose side are you on?! -- Calvin

 

[Richard Tobin]

Unfortunately, the ? might actually be supposed to be "fl" instead. (Or
potentially lots of other things, too, but the C Standard should only
have fi and fl ligatures.)

It has some ffi ligatures too (e.g. in "suffix").

-- Richard

 

[Keith Thompson]

Unfortunately, the ? might actually be supposed to be "fl" instead. (Or
potentially lots of other things, too, but the C Standard should only
have fi and fl ligatures.)

Or it could be an actual question mark. (In practice, I rarely if
ever quote so much from the standard that a manual search-and-replace
is impractical.)

 

[lawrence.jones]

It has some ffi ligatures too (e.g. in "suffix").

Are you sure? The original PostScript most definitely does not, and I
wouldn't expect the conversion to PDF to change that.

-- Larry Jones

Moms and reason are like oil and water. -- Calvin

 

[Richard Tobin]

It has some ffi ligatures too (e.g. in "suffix").

[/QUOTE]

Are you sure? The original PostScript most definitely does not, and I
wouldn't expect the conversion to PDF to change that.

I am looking at the BSI versions, so I suppose it is possible
that they have been re-typeset.

In C99+TC1, in the table of contents on page vi, the entry 7.12.12 has
an ff ligature in "difference".

In the integer-constant production on page 54, there is an ffi
ligature in "integer-suffix".

The ffi ligature is also there in my BSI C90 copy.

-- Richard

 

[lawrence.jones]

I am looking at the BSI versions, so I suppose it is possible
that they have been re-typeset.

I'm pretty sure they were, which would explain it.

-- Larry Jones

I don't like these stories with morals. -- Calvin