integer and floating-point bit pattern

[Mantorok Redgormor]

Would the following determine if the bit pattern for
floating point 0.0 and integer 0 are the same?

#include <stdio.h>
int main(void)
<%
if(0 == 0.0f)
puts("Bit pattern is the same.");

return 0;
%>
Also is it undefined behavior for failure
to include the proper header file for any
function or just functions that accept a
variable number of arguments?

[Mike Wahler]

"Mantorok Redgormor" <ne*****@tokyo.com> wrote in message
news:41**************************@posting.google.c om...

Would the following determine if the bit pattern for
floating point 0.0 and integer 0 are the same?
No.
#include <stdio.h>
int main(void)
<%
if(0 == 0.0f)
puts("Bit pattern is the same.");
puts ("VALUE is the same.");

return 0;
%>
Use a pointer to unsigned char ('unsigned char*')
to inspect individual bytes of other types.

#include <stdio.h>
#include <string.h>

int main(void)
{
int i = 0;
float f = 0;
unsigned char *pi = (unsigned char*)&i;
unsigned char *pf = (unsigned char*)&f;
int eq_size = sizeof i == sizeof f;

if(eq_size && !memcmp(pi, pf, sizeof i))
puts("match");
else
puts("no match");

return 0;
}
Also is it undefined behavior for failure
to include the proper header file for any
function or just functions that accept a
variable number of arguments?

For C99 I believe it's a constraint violation.
I don't think it's UB in either case.
Just #include the necessary header, and forget it.

-Mike

[Jack Klein]

On 1 Oct 2003 13:56:10 -0700, ne*****@tokyo.com (Mantorok Redgormor)
wrote in comp.lang.c:

Would the following determine if the bit pattern for
floating point 0.0 and integer 0 are the same?

#include <stdio.h>
int main(void)
<%
if(0 == 0.0f)
puts("Bit pattern is the same.");

return 0;
%>
Also is it undefined behavior for failure
to include the proper header file for any
function or just functions that accept a
variable number of arguments?

Mike already answered your first question, he was a little unsure
about the second.

It is not and has never been a requirement in C that you include
header files, except in a few cases where data types with
implementation-defined types and members (such as time_t, FILE, etc.).

Prior to the current (1999) standard you did not need a prototype or a
declaration to call a function that returned int and accepted a fixed
number and type of arguments, if all the argument types were those
provided by default promotions.

Under the current standard, there must be at least a declaration in
scope for any function you call, specifying the return type. Implicit
int is illegal, including the return type of functions. The
declaration does not need to be a prototype if the function accepts a
fixed number and type of arguments if the types are the default
promotions.

Since the very first 1989 ANSI standard, it produces undefined
behavior to call a variadic function without a full prototype in
scope.

It is perfectly valid under all versions of the C standard to provide
your own prototype for a standard function so long as you get it
correct.

If you write a prototype equivalent to:

char *strchr(const char *s, int c);

....then you can call this function without including <string.h>.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Mike Wahler]

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:ds********************************@4ax.com...

Also is it undefined behavior for failure
to include the proper header file for any
function or just functions that accept a
variable number of arguments?

Mike already answered your first question, he was a little unsure
about the second.

And now I'm not. :-)

[snip good explanation]

Thanks, Jack.

-Mike

[Mantorok Redgormor]

Jack Klein <ja*******@spamcop.net> wrote in message news:<ds********************************@4ax.com>. ..

On 1 Oct 2003 13:56:10 -0700, ne*****@tokyo.com (Mantorok Redgormor)
wrote in comp.lang.c:

Would the following determine if the bit pattern for
floating point 0.0 and integer 0 are the same?

#include <stdio.h>
int main(void)
<%
if(0 == 0.0f)
puts("Bit pattern is the same.");

return 0;
%>
Also is it undefined behavior for failure
to include the proper header file for any
function or just functions that accept a
variable number of arguments?

Mike already answered your first question, he was a little unsure
about the second.

It is not and has never been a requirement in C that you include
header files, except in a few cases where data types with
implementation-defined types and members (such as time_t, FILE, etc.).

Prior to the current (1999) standard you did not need a prototype or a
declaration to call a function that returned int and accepted a fixed
number and type of arguments, if all the argument types were those
provided by default promotions.

Under the current standard, there must be at least a declaration in
scope for any function you call, specifying the return type. Implicit
int is illegal, including the return type of functions. The
declaration does not need to be a prototype if the function accepts a
fixed number and type of arguments if the types are the default
promotions.

Since the very first 1989 ANSI standard, it produces undefined
behavior to call a variadic function without a full prototype in
scope.

It is perfectly valid under all versions of the C standard to provide
your own prototype for a standard function so long as you get it
correct.

If you write a prototype equivalent to:

char *strchr(const char *s, int c);

...then you can call this function without including <string.h>.

Thanks for the response.

I'm puzzled about one thing though. Why is unsigned char *
the preferred type for handling underlying representations
of types?

[Mike Wahler]

"Mantorok Redgormor" <ne*****@tokyo.com> wrote in message
news:41**************************@posting.google.c om...

I'm puzzled about one thing though. Why is unsigned char *
the preferred type for handling underlying representations
of types?

In simplest terms:

Because the language specification guarantees that it will work.
No such guarantee is made for any other type.

-Mike