Typecasting in C

[andynaik]

Hi,
Whenever we type in this code
int main()
{
printf("%f",10) ;
}
we get an error. We can remove that by using #pragma directive t
direct that to the 8087. Even after that the output is 0.00000 and no
10.0000. Can anybody tell me why it is like that and why typecasting i
not done in this case?
-
andynai
-----------------------------------------------------------------------
Posted via http://www.codecomments.co
-----------------------------------------------------------------------

[Martin Ambuhl]

jacob navia wrote:

"Dan Pop" <Da*****@cern.c h> a écrit dans le message de
news:cb******** **@sunnews.cern .ch...

OTOH, lcc-win32 silently accepts printf("%d\n", "foo"), which is very
bad, considering the relative positions of the D and S keys on most
keyboard layouts (i.e. it is a fairly frequent mistake to type d
when you mean s).

I pondered a long time about that one, since it is perfectly legal to
do:

char *p;
...

printf("The address is %d\n",p);

The specifier for a pointer is "%p" and it expects a (void *) argument.
This supposedly "legal" line should be
printf("The address is %p\n", (void *)p);

Please stop misleading people who might think you know what you're
talking about.

specially in debugging code.

Granted, this is weird, but how to discriminate between
legal and wrong usage?

You "legal" usage is _wrong_. There is no need to discriminate between
your error and that which is wrong.

[jacob navia]

The expression

printf("the address is: 0x%x\n",p);

where p is some pointer appears in several million lines in
existing code.

The warnings can become a nuisance and people would stop
using this feature. Personally I think warnings should be
kept to the essential ones, warnings that would uncover a
possible error.

Strictly speaking you should use %p, but I have almost
never seen it in debugging code, where this conversion is
used.

To the contrary of your expectations, I work to make a usable
compiler, not one that will please the purists around c.l.c

[Randy Howard]

In article <cb**********@n ews-reader1.wanadoo .fr>, ja***@jacob.rem comp.fr
says...

I pondered a long time about that one, since it is perfectly legal to
do:

char *p;
...

printf("The address is %d\n",p);

specially in debugging code.

I just lost any faith I might have had in lcc-win32. Thanks for
the flashing warning label.

[Dan Pop]

In <2k************ @uni-berlin.de> Martin Ambuhl <ma*****@earthl ink.net> writes:

andynaik wrote:

Hi,
Whenever we type in this code
int main()
{
printf("%f",10) ;
}
we get an error. We can remove that by using #pragma directive to
direct that to the 8087. Even after that the output is 0.00000 and not
10.0000. Can anybody tell me why it is like that and why typecasting is
not done in this case??
Because you forgot
#include <stdio.h>
You also forgot to terminate the last line of output with an end-of-line
character. ^^^^^^^^^^^

^^^^^^^^^
In C, it is called new-line character, even if no line follows. You must
be confusing with the end-of-line *indicator* (which needs not be a
character).
The first mistake, omission of the prototype for a variadic function, is
always an error. The second is an error in code designed to be
portable, and may result in behavior you were not expecting.

Neither of then having anything to do with the real cause of the OP's
problem: type mismatch in a printf call, which will continue to manifest
even after including <stdio.h> and adding the new-line character.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Harti Brandt]

On Tue, 29 Jun 2004, jacob navia wrote:

jn>The expression
jn>
jn>printf("the address is: 0x%x\n",p);
jn>
jn>where p is some pointer appears in several million lines in
jn>existing code.
jn>
jn>The warnings can become a nuisance and people would stop
jn>using this feature. Personally I think warnings should be
jn>kept to the essential ones, warnings that would uncover a
jn>possible error.
jn>
jn>Strictly speaking you should use %p, but I have almost
jn>never seen it in debugging code, where this conversion is
jn>used.
jn>
jn>To the contrary of your expectations, I work to make a usable
jn>compiler, not one that will please the purists around c.l.c

That has nothing to do with purism. Ever cared to work on a machine where
sizeof(void *) > sizeof(int)? The nearest to correct thing to do if you
happen to have a printf() without %p would be to use %lx and cast the
pointer to an unsigned long.

harti

[Dan Pop]

In <2e************ *************** ***@news.thenew sgroups.com> andynaik <an************ *@mail.codecomm ents.com> writes:

Whenever we type in this code
int main()
{
printf("%f",10 );
}
we get an error. We can remove that by using #pragma directive to
direct that to the 8087. Even after that the output is 0.00000 and not
10.0000. Can anybody tell me why it is like that and why typecasting is
not done in this case??

Since type casting is a programming construct, it is you who have to
explain us why you have omitted it from your program.

If your question is why 10 wasn't *automatically converted*, which is
something *completely* different from type casting, the answer is that
it is located in the variable argument part of the printf call and,
therefore, it is subject to the default argument promotions, *only*.
In other words, although the compiler is allowed to have special
knowledge about printf, it is not required to have such knowledge or to
use it for fixing any mismatch between the format string and the rest
of the arguments.

Furthermore, because printf is a variadic function, you *must* provide
a correct declaration for it, before calling it. So, including <stdio.h>
is NOT optional in programs using printf and/or scanf. And a new-line
character in the format string wouldn't hurt, either: the shell prompt
*may* overwrite the last line of output, otherwise. Or be appended to it,
which, even if less destructive, is still far from desirable.

As a last remark, NOW it is the right time to get used to properly
indenting your code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <Xn************ *************** @212.27.42.65> Emmanuel Delahaye <em**********@n oos.fr> writes:

In 'comp.lang.c', andynaik <an************ *@mail.codecomm ents.com> wrote:

Hi,
Whenever we type in this code
int main()
{
printf("%f",10) ;
}
we get an error.
Compiling MAIN.C:
Warning MAIN.C 4: Call to function 'printf' with no prototype
Warning MAIN.C 5: Function should return a value
Linking EXE\PROJ.EXE:

You're sorely mistaken if you believe that compiler diagnostics *by
themselves* prove anything at all.
This code invokes an undefined behaviour (UB).
Which means that no diagnostic is required. Furthermore, even if all the
diagnostics of your compiler are fixed, the program is still as broken
as it was in the first place.
It is mandatory to supply a
prototype when using a variadic function. Add

#include <stdio.h>

That said, 10 is a int. "%f" is expecting a double. If you want to printf a
double, use 10.0, or the (double) typecast.
Did you actually try to understand the OP's question? He *knows* that
"%f" is expecting a double and he is asking why the compiler doesn't
convert 10 to double. WHERE are you addressing this question in your
reply?
Finally, some old Borland C compilers anre buggy and forget to link the
floating point library un such a case. This little hack can help:

Since when are some old Borland C compilers topical to this newsgroup?
Aren't they properly handled by the FAQ?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <cb**********@n ews-reader3.wanadoo .fr> "jacob navia" <ja***@jacob.re mcomp.fr> writes:

"Alex Fraser" <[e-mail] > a écrit dans le message de
news:2k******* ****@uni-berlin.de...

"andynaik" <an************ *@mail.codecomm ents.com> wrote in message
news:2e******** *************** *******@news.th enewsgroups.com ...

> Whenever we type in this code
> int main()
> {
> printf("%f",10) ;
> }
> we get an error. We can remove that by using #pragma directive to
> direct that to the 8087.

Means nothing to me (compiler specifics are off-topic here).

> Even after that the output is 0.00000 and not 10.0000. Can anybody tell
> me why it is like that and why typecasting is not done in this case??

Read section 15 in the FAQ. Post back if you still have questions.
http://www.eskimo.com/~scs/C-faq/s15.html

The FAQ should mention that some compilers DO test the arguments
for sprintf/printf/fprintf etc for validity.

But they *still* don't perform any automatic conversions on the arguments,
to make them match the format string (other than the default argument
promotions).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[jacob navia]

"Harti Brandt" <br****@dlr.d e> a écrit dans le message de
news:20******** ***********@bea gle.kn.op.dlr.d e...

On Tue, 29 Jun 2004, jacob navia wrote:
That has nothing to do with purism. Ever cared to work on a machine where
sizeof(void *) > sizeof(int)?

In the next implementation of lcc-win32 that will be the case (64 bit
machine).

In THAT environment I will issue the warning for all pointer/int
conversions.

In an environment where sizeof(int)==si zeof(void*) many people
(including me) write printf("pointer value=%#x\n",p) ; to debug
a piece of code. The compiler spitting you hundreds of warnings
would only have the consequence of people IGNORING all warnings.

lcc-win32 has several levels of warnings. After this discussion I have added
a warning when the warning level is higher than normal for all
implicit pointer/int conversions in the printf formats.

It is a pity that people here like to have an atmosphere of
aggresivity that is very boring.

In any case this discussion was positive for me (and lcc-win32).
I have been able to improve lcc-win32 a bit.

Thanks for your time.

[jacob navia]

"Randy Howard" <ra*********@FO OverizonBAR.net > a écrit dans le message de
news:MP******** *************** *@news.verizon. net...

In article <cb**********@n ews-reader1.wanadoo .fr>, ja***@jacob.rem comp.fr
says...

I just lost any faith I might have had in lcc-win32. Thanks for
the flashing warning label.

Mr Howard

It is a pity that people here like to have an atmosphere of
aggresivity that is so boring.

In any case this discussion was positive for me (and lcc-win32).
I have been able to improve lcc-win32 a bit.

Thanks for your time.