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
-----------------------------------------------------------------------

[Dan Pop]

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

The expression

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

where p is some pointer appears in several million lines in
existing code.
If you think that the amount of existing broken code can prove anything,
you're sorely mistaken. The days when all the world was a 32-bit
platform are gone...
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.
In your stupidity, you don't realise that this is a genuine error, it
just doesn't manifest on *your* platform. Try to engage your brain
and think about platforms with 32-bit int's and 64-bit pointers
(increasingly common since DEC released Alpha OSF/1 in 1992).

To show you that the issue is *real* and not invented ad-hoc:

lx64:~/tmp 11> uname -m
x86_64
lx64:~/tmp 12> cat test.c
#include <stdio.h>

int main(void)
{
int i;
printf("%#x %p\n", &i, (void *)&i);
return 0;
}

lx64:~/tmp 13> gcc test.c
lx64:~/tmp 14> ./a.out
0xbffff00c 0x7fbffff00c
lx64:~/tmp 15> gcc -Wall test.c
test.c: In function `main':
test.c:6: warning: unsigned int format, pointer arg (arg 2)

As you can see, the two values are different: %x has lost information.
So, the people developing their code on your compiler will have a bad
surprise when trying to use it elsewhere and you believe that you're
doing them a favour!
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

If you think you're doing your users any service by not diagnosing
their genuine mistakes, simply because they *accidentally* work on
your platform, you're even more stupid than I thought. People like you
have no business messing with compilers and libraries.

The FAQ *should* contain the following question: "Why should I avoid
lcc-win32 like the plague?". But the answer would significantly increase
its current size...

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

[Arthur J. O'Dwyer]

On Tue, 29 Jun 2004, jacob navia wrote:

The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.

Has anyone besides Jacob ever seen this construct (or anything
similar) in real-world code? I've never encountered it. The
usual idiom in my part of the universe is more like

printf("(%d) %p\n", p!=NULL, (void*)p);

which has the benefit of (a) telling you something useful, and
(b) being standard, warning-less C code.

Who's been using "%d" or "%x" to print *pointer* values?

-Arthur

[Alex Monjushko]

Arthur J. O'Dwyer <aj*@nospam.and rew.cmu.edu> wrote:

On Tue, 29 Jun 2004, jacob navia wrote:

The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.

Has anyone besides Jacob ever seen this construct (or anything
similar) in real-world code? I've never encountered it. The
usual idiom in my part of the universe is more like printf("(%d) %p\n", p!=NULL, (void*)p); which has the benefit of (a) telling you something useful, and
(b) being standard, warning-less C code. Who's been using "%d" or "%x" to print *pointer* values?

It is quite common in legacy code. Especially in the stuff that
got carried over from the pre-ANSI days.

--
Alex Monjushko (mo*******@hotm ail.com)

[Harti Brandt]

On Tue, 29 Jun 2004, Arthur J. O'Dwyer wrote:

AJO>
AJO>On Tue, 29 Jun 2004, jacob navia wrote:
AJO>>
AJO>> The expression
AJO>> printf("the address is: 0x%x\n",p);
AJO>> where p is some pointer appears in several million lines in
AJO>> existing code.
AJO>
AJO> Has anyone besides Jacob ever seen this construct (or anything
AJO>similar) in real-world code? I've never encountered it. The
AJO>usual idiom in my part of the universe is more like
AJO>
AJO> printf("(%d) %p\n", p!=NULL, (void*)p);
AJO>
AJO>which has the benefit of (a) telling you something useful, and
AJO>(b) being standard, warning-less C code.
AJO>
AJO> Who's been using "%d" or "%x" to print *pointer* values?

%p is a quite new feature for printf(). Neither V7 nor BSD had this, so
the natural way of printing pointers was %x. Don't assume that everybody
out there does a daily update of it's compilers and libraries to the
current gcc.

harti

[Keith Thompson]

"jacob navia" <ja***@jacob.re mcomp.fr> writes:

The expression

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

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

Then there are several million errors, and you'd be doing your users a
favor by letting them know.

For example, on an IA-64 system:

#include <stdio.h>
int main(void)
{
char *p = "hello";
printf("Using %%x: p = 0x%x\n", p); /* wrong */
printf("Using %%p: p = %p\n", (void*)p); /* right */
return 0;
}

produces the following output:

Using %x: p = 0x7c0
Using %p: p = 0x4000000000000 7c0

I suspect that platforms with 32-bit ints and 64-bit pointers are
going to become much more common over the next few years. The sooner
programmers realize that all the world's not a VAX^H^H^H x86, the
better. Even if the sizes happen to match, it's still undefined
behavior, and any number of things can go wrong.

If you really want to make sure the address value is displayed in
hexadecimal, and you're willing to assume that pointers and ints are
the same size (e.g., you're writing a quick-and-dirty debugging
statement that will be deleted before the code could ever be ported to
another platform), you can always cast the pointer value to unsigned
int to inhibit the warning. The result may or may not be meaningful,
but at least it avoids undefined behavior.

Or you can just use "%p", which exists for exactly this purpose.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Randy Howard]

In article <Pi************ *************** *******@unix48. andrew.cmu.edu> ,
aj*@nospam.andr ew.cmu.edu says...

On Tue, 29 Jun 2004, jacob navia wrote:

The expression
printf("the address is: 0x%x\n",p);
where p is some pointer appears in several million lines in
existing code.

Has anyone besides Jacob ever seen this construct (or anything
similar) in real-world code? I've never encountered it.

Unfortunately yes, but not in quite some time. I ran into it
fairly often in the MS-DOS and early Windows days. (Maybe Mr.
Schildt used it a lot in his books???) It was probably in a fair
amount of older legacy UNIX code as well, but I can't recall an
example offhand.

Usually they at least cast the type of p to something appropriate
for the %d or %x on the platform. Every time I encounter something
like that, I fix it, but it doesn't happen much anymore, plus I very
rarely get stuck maintaining code that poor these days.

--
Randy Howard (2reply remove FOOBAR)
"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." - Henry Petroski

[Randy Howard]

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

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

Jacob, if you ever (or already) support 64-bit AMD Opteron/AthlonFX or the
Intel clones of same, you're users are going to be in for a rude awakening
when they get to work porting. Yes, it may be so common on 32-bit platforms
for programmers to make assumptions that it *seems* like you're doing them
a favor to ignore it, in the long run, when people WILL be porting a lot
of legacy code to new platforms, it will be a hindrance, not a benefit.

--
Randy Howard (2reply remove FOOBAR)
"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." - Henry Petroski

[Randy Howard]

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

"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.

So people using your 32-bit compiler to develop code which will migrate
to 64 in the future will have to wait until later to be warned of possible
errors in their program. That's not a good idea.
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.
You write this in new code? Why? I could understand you trying to
support legacy code through some sort of "shut up warnings about this"
mode, but not by default, and certainly don't understand writing new
code with a modern compiler as you describe.
The compiler spitting you hundreds of warnings
would only have the consequence of people IGNORING all warnings.
Strange, I try very hard to get my code to compile (on multiple platforms,
with varying compilers) with no warnings at all, using the highest warning
level on each compiler. It's not always possible, but I try very hard to
do so without bastardizing the source to get there. I have met programmers
that did ignore all warnings, but they were not around long enough in any
case to have a lasting impact.
It is a pity that people here like to have an atmosphere of
aggresivity that is very boring.

I didn't mean to be aggressive earlier, I think it was more *shock* than
animosity. I would have expected this discussion 10 years ago here, not
today, especially in light of the age of the standards that allow it to
be avoided, not to mention the 64-bit transitions currently very active
in a lot of places.

--
Randy Howard (2reply remove FOOBAR)
"The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry..." - Henry Petroski

[jacob navia]

"Keith Thompson" <ks***@mib.or g> a écrit dans le message de
news:ln******** ****@nuthaus.mi b.org...

"jacob navia" <ja***@jacob.re mcomp.fr> writes:

The expression

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

where p is some pointer appears in several million lines in
existing code.
Then there are several million errors, and you'd be doing your users a
favor by letting them know.

If they set the debug level to high then yes. If not, the compiler
accepts it. I think this discussion has shown me that
maybe a warning is needed, if the programmer wishes.

lcc-win32 (as its name implies) is a 32 bit system. I am working
in the 64 bit version already, but that is another topic.

For example, on an IA-64 system:

#include <stdio.h>
int main(void)
{
char *p = "hello";
printf("Using %%x: p = 0x%x\n", p); /* wrong */
printf("Using %%p: p = %p\n", (void*)p); /* right */
return 0;
}

produces the following output:

Using %x: p = 0x7c0
Using %p: p = 0x4000000000000 7c0

Yes, this is one of the reasons I think a warning should be
issued if the programmer wishes. It helps porting code
from 32-->64 bits.
I suspect that platforms with 32-bit ints and 64-bit pointers are
going to become much more common over the next few years. The sooner
programmers realize that all the world's not a VAX^H^H^H x86, the
better. Even if the sizes happen to match, it's still undefined
behavior, and any number of things can go wrong.

Yes. I started porting the code and it is hard. Warnings like this
could improve the situation. In any case in the 64 bit system a warning
will be issued since sizeof(int) != sizeof(void *).
If you really want to make sure the address value is displayed in
hexadecimal, and you're willing to assume that pointers and ints are
the same size (e.g., you're writing a quick-and-dirty debugging
statement that will be deleted before the code could ever be ported to
another platform), you can always cast the pointer value to unsigned
int to inhibit the warning.
But this is just effort for throwaway code. Why bother?

Most of those printf statements are for situations where the
debugger is absent.

I started programming when this statements were the only
way of debugging since there wasn't any debugger.

And I wrote (to see if a pointer had a value) %x and was done
with it.

This has worked since a long time. Yes, I know about
%p, but I didn't bother. Why? It continued to work.
The result may or may not be meaningful,
but at least it avoids undefined behavior.

Or you can just use "%p", which exists for exactly this purpose.

Yes, I think I will be forced to write that in the 64 bit system.

I am wary of forcing casts to please the compiler... In a 32
bit system where sizeof void * is the same as sizeof int, this
warning has no sense really, and should be optional.

Do not clutter output. Filter it. Make more verbose
options available but choose a sensible default:

do not clutter...

[jacob navia]

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

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

To the contrary of your expectations, I work to make a usable
compiler, not one that will please the purists around c.l.c
Jacob, if you ever (or already) support 64-bit AMD Opteron/AthlonFX or the
Intel clones of same, you're users are going to be in for a rude awakening
when they get to work porting. Yes, it may be so common on 32-bit

platforms for programmers to make assumptions that it *seems* like you're doing them
a favor to ignore it, in the long run, when people WILL be porting a lot
of legacy code to new platforms, it will be a hindrance, not a benefit.

Yes, I added an optional warning. If you want this (and other
warnings) you set higher warning level.

64 bit systems were never a succes, since at least a few
years. Many of them started but never become popular.

And I am sure that issues like %x or %p will be the least
of the problems I will face. Data size bloat, code size bloat...
64 bits is very expensive...

Need more than 4GB of memory recently?

If we bloat things that doesn't make them faster. Twice as
much data needs to be loaded, read-in, etc. This
doesn't make for very significant improvements. But this
is another topic.