By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,987 Members | 1,607 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,987 IT Pros & Developers. It's quick & easy.

how the following code works?

P: n/a
main() {
float a = 5.375;
char *p;
int i;
p = (char*)&a;
for(i=0;i<=3;i++)
printf("%02x",(unsigned char)p);
}

the above code gives the binary representation of a.
how does it work?

Jun 16 '07 #1
Share this Question
Share on Google+
16 Replies


P: n/a
In article <11*********************@e9g2000prf.googlegroups.c om>,
Ravi <ra*********@gmail.comwrote:
>main() {
float a = 5.375;
char *p;
int i;
p = (char*)&a;
for(i=0;i<=3;i++)
printf("%02x",(unsigned char)p);
}

the above code gives the binary representation of a.
how does it work?
It doesn't.
dave
(it appears to be an attempt to examine the bytes representing an object
of floating-point types, but contains at least one obvious error, one
subtle error, and one gratuitious assumption.)

--
Dave Vandervies dj******@csclub.uwaterloo.ca
P.J. Plauger has a valid reason [...] although I would say that was
more to do with his customers being less than sensible.
--Flash Gordon in comp.lang.c
Jun 16 '07 #2

P: n/a
Ravi wrote:
>
main() {
float a = 5.375;
char *p;
int i;
p = (char*)&a;
for(i=0;i<=3;i++)
printf("%02x",(unsigned char)p);
}

the above code gives the binary representation of a.
how does it work?
It doesn't work at all.

/* BEGIN new.c */

#include <stdio.h>

int main(void)
{
float a = 5.375;
unsigned char *p;
size_t i;

p = (unsigned char *)&a;
for (i = 0; i != sizeof a; ++i) {
printf("%02x ", p[i]);
}
putchar('\n');
return 0;
}

/* END new.c */
--
pete
Jun 16 '07 #3

P: n/a

"Ravi" <ra*********@gmail.comwrote in message
news:11*********************@e9g2000prf.googlegrou ps.com...
main() {
float a = 5.375;
char *p;
int i;
p = (char*)&a;
for(i=0;i<=3;i++)
printf("%02x",(unsigned char)p);
}

the above code gives the binary representation of a.
how does it work?
Let's rewrite slightly more professionally.

#include <stdio.h>

void dump(void *bytes, int N)
{
int i;
unsigned char *cbytes = bytes;

for(i=0;i<N;i++)
printf("%02x", cbytes[i]);
printf("\n");
}

int main(void)
{
float a = 123.567;

dump(&a, sizeof(float));
return 0;
}

Now you ought to see how the program works. Plus you have a handy little
routine you can cut and paste any time you need to examine an object's
binary representation.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Jun 16 '07 #4

P: n/a
On Jun 16, 10:38 am, Ravi <ra.ravi....@gmail.comwrote:
main() {
float a = 5.375;
char *p;
int i;
p = (char*)&a;
for(i=0;i<=3;i++)
printf("%02x",(unsigned char)p);

}
oops, you had taken liberty over the size of float!
>printf("%02x",(unsigned char)p);
Never know what you are trying to do by this statement.
>
the above code gives the binary representation of a.
No, it doesn't!
Moreover, even if you correct all the mistakes, I don't think you will
get the binary representation, unless CHAR_BIT==1,in which case your
implementation is non-conforming!

You will get only "byte representation".
how does it work?
It doesn't work at all.
Jun 16 '07 #5

P: n/a
Ravi said:
main() {
float a = 5.375;
char *p;
int i;
p = (char*)&a;
for(i=0;i<=3;i++)
printf("%02x",(unsigned char)p);
}

the above code gives the binary representation of a.
how does it work?
It doesn't.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jun 16 '07 #6

P: n/a

"pete" <pf*****@mindspring.comha scritto nel messaggio
news:46**********@mindspring.com...
Ravi wrote:
>>
main() {
float a = 5.375;
char *p;
int i;
p = (char*)&a;
for(i=0;i<=3;i++)
printf("%02x",(unsigned char)p);
}

the above code gives the binary representation of a.
how does it work?

It doesn't work at all.

/* BEGIN new.c */

#include <stdio.h>

int main(void)
{
float a = 5.375;
unsigned char *p;
size_t i;

p = (unsigned char *)&a;
for (i = 0; i != sizeof a; ++i) {
Any reason to use != where the rest of the world uses <?
(Just curious, I know that *here* they do the same.)
printf("%02x ", p[i]);
}
putchar('\n');
return 0;
}

/* END new.c */
--
pete

Jun 16 '07 #7

P: n/a
Army1987 wrote:
"pete" <pf*****@mindspring.comha scritto nel messaggio
news:46**********@mindspring.com...
> for (i = 0; i != sizeof a; ++i) {
Any reason to use != where the rest of the world uses <?
(Just curious, I know that *here* they do the same.)
In such constructs I usually put != instead of < as well. It doesn't matter
here, and it's the same thing that would be required in just a slightly
different example:
for (p = start; p != NULL; p = p->next)
Jun 16 '07 #8

P: n/a
In article <f5**********@tdi.cu.mi.it>, Army1987 <pl********@for.itwrote:
> for (i = 0; i != sizeof a; ++i) {
>Any reason to use != where the rest of the world uses <?
There is a theory that it's better to use "<", because if the variable
somehow gets to be bigger than the terminating value, the loop will
still stop. I believe this is sometimes considered to be "defensive
programming".

There is another theory that this is a really bad idea, because it will
hide bugs in your program (how did the variable get the bogus value?),
and you should instead use "!=" to make the error get noticed sooner.

From the point of view of readability, I think that "<" is more likely to
express the way the programmer is thinking about it - the terminating
value expresses the end of a range, rather than a sentinel value as
is "while(*p++ != '\0')".

So using "!=" seems to me to be in the same class of idioms as writing
"if(1 == a)" rather than "if(a == 1)" - it might sometimes result in
earlier error detection, but at the expense of naturalness and hence
readability.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 16 '07 #9

P: n/a
Harald van D?k wrote:
>
Army1987 wrote:
"pete" <pf*****@mindspring.comha scritto nel messaggio
news:46**********@mindspring.com...
for (i = 0; i != sizeof a; ++i) {
Any reason to use != where the rest of the world uses <?
(Just curious, I know that *here* they do the same.)

In such constructs I usually put != instead of < as well. It doesn't matter
here, and it's the same thing that would be required in just a slightly
different example:
for (p = start; p != NULL; p = p->next)
'<' is safer. If something glitches the value of i.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 16 '07 #10

P: n/a
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>'<' is safer. If something glitches the value of i.
Why is it safer for a loop to finish and the program continue if the
value of a variable has been "glitched"?

In many cases, having the loop continue so that the program gets a
segmentation fault seems safer.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 16 '07 #11

P: n/a
Richard Tobin wrote:
CBFalconer <cb********@maineline.netwrote:
>>'<' is safer. If something glitches the value of i.

Why is it safer for a loop to finish and the program continue if
the value of a variable has been "glitched"? In many cases,
having the loop continue so that the program gets a segmentation
fault seems safer.
Say the loop just performs a fairly lengthy calculation. If i gets
above the terminal value things can go on for 2^32 iterations.
You'll probably never find it, because the use will assume a system
crash. Obviously the optimum depends on the situation.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 16 '07 #12

P: n/a
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>Say the loop just performs a fairly lengthy calculation. If i gets
above the terminal value things can go on for 2^32 iterations.
You'll probably never find it, because the use will assume a system
crash.
Huh? Why would the user assume the system has crashed just because
some program does not terminate?
>Obviously the optimum depends on the situation.
Yes, certainly. For the programs I write as part of my work, I would
much prefer a segmentation fault or non-termination to termination
with an undetected incorrect answer, because the aim of the program is
to find the right answer. But there are other situations: for a
computer game crashing may be the most annoying outcome for the user.

I conclude that there is no general rule on safety grounds for whether
to choose "<" or "!=" as a loop termination test. So I just write
whatever seems most natural.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jun 16 '07 #13

P: n/a
Richard Tobin wrote:
CBFalconer <cb********@maineline.netwrote:
>Say the loop just performs a fairly lengthy calculation. If i gets
above the terminal value things can go on for 2^32 iterations.
You'll probably never find it, because the use will assume a system
crash.

Huh? Why would the user assume the system has crashed just because
some program does not terminate?
Well, I would.
>
>Obviously the optimum depends on the situation.

Yes, certainly. For the programs I write as part of my work, I would
much prefer a segmentation fault or non-termination to termination
with an undetected incorrect answer, because the aim of the program is
to find the right answer. But there are other situations: for a
computer game crashing may be the most annoying outcome for the user.

I conclude that there is no general rule on safety grounds for whether
to choose "<" or "!=" as a loop termination test. So I just write
whatever seems most natural.
Another thing, you can check the termination condition after exit
easily, with something like "if (i != endvalue) makenoises(...);",
and not disturb the normal running. Now you can make the message
detailed.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 17 '07 #14

P: n/a
Army1987 wrote:
>
"pete" <pf*****@mindspring.comha scritto nel messaggio
news:46**********@mindspring.com...
for (i = 0; i != sizeof a; ++i) {
Any reason to use != where the rest of the world uses <?
(Just curious, I know that *here* they do the same.)
I consider != to be conceptually simpler than <

--
pete
Jun 17 '07 #15

P: n/a
pete wrote:
Army1987 wrote:
>>
"pete" <pf*****@mindspring.comha scritto nel messaggio
news:46**********@mindspring.com...
for (i = 0; i != sizeof a; ++i) {
Any reason to use != where the rest of the world uses <?
(Just curious, I know that *here* they do the same.)

I consider != to be conceptually simpler than <
Yes, but if the increment is changed to i+=2 then the above
loop will never terminate if "sizeof a" is odd. Using less
than will not have the same problem.

Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Gambling(n): A discretionary tax on those asleep during high school
maths.
Jun 17 '07 #16

P: n/a

"Richard Tobin" <ri*****@cogsci.ed.ac.ukha scritto nel messaggio
news:f5***********@pc-news.cogsci.ed.ac.uk...
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>>'<' is safer. If something glitches the value of i.

Why is it safer for a loop to finish and the program continue if the
value of a variable has been "glitched"?

In many cases, having the loop continue so that the program gets a
segmentation fault seems safer.
for (i = 0; i < n; i++) {
do_stuff();
}
assert(i == n);
Jun 17 '07 #17

This discussion thread is closed

Replies have been disabled for this discussion.