how the following code works?

[Ravi]

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?

 

[Dave Vandervies]

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

 

[pete]

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);
}
putchar('\n');
return 0;
}

/* END new.c */

 

[Malcolm McLean]

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);
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.

 

[CryptiqueGuy]

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.

 

[Richard Heathfield]

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.

 

[Army1987]

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);
}
putchar('\n');
return 0;
}

/* END new.c */

 

[Harald van =?UTF-8?B?RMSzaw==?=]

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)

 

[Richard Tobin]

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

 

[CBFalconer]

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.

 

[Richard Tobin]

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

 

[CBFalconer]

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.

 

[Richard Tobin]

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

 

[CBFalconer]

Huh? Why would the user assume the system has crashed just because
some program does not terminate?

Well, I would.

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.

 

[pete]

"pete" <[email protected]> ha scritto nel messaggio

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 <

 

[Erik de Castro Lopo]

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

 

[Army1987]

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