undefined behavior or not undefined behavior? That is the question

[Irrwahn Grausewitz]

But is NULL defined in stdio.h as mr. O' Dwyer suggested?

According to the C99 standard, NULL shall be defined
in (at least?) these standard headers:

locale.h
stddef.h
stdio.h
stdlib.h
string.h
time.h
wchar.h


<snip>

HTH
Regards

 

[pete]

But is NULL defined in stdio.h as mr. O' Dwyer suggested?

Yes, and in many other headers too.
Don't you know of any stdio functions which can return NULL ?
Are you familiar with fgets ?

It just checks if the first byte of an int is 0 or anything else..
If it is zero, it is a big endian machine, else a little endian..

You snipped: "There's also the possibility of mixed endian."
Again,
there are more choices allowed by the C standard
than just big or little.

And I am not assuming that it is a 32-bit machine..

I'm sorry. I misinterpreted your comment which you snipped:

I am only using the first byte..
So being 32-bit or 64-bit is irrelevant...

If your int representation has padding bits,
then it's possible that one of the bytes might have a set padding
bit which is not part of the value of ((int)1),
but which shows up during byte examination.

 

[Arjan Kenter]

...

[sig includes]

#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little) : p(Big); return 0;}

Oh yeah, and that code isn't c.l.c-compliant. [ISO standard
C doesn't really give any useful definitions regarding endianness,
nor does it guarantee that the attempted evaluation of *(char*)&v
won't invoke undefined behavior on the DeathStation 9000.]

It would seem to be C99 complient. [Even if the output won't necessarily be
meaningful.]

And by the way, if sizeof(char) == sizeof(int) on your implementation, the
output isn't going to be very useful anyway (remember, a char is not necessarily
a byte!) Or is that what you were getting at...

--
ir. H.J.H.N. Kenter ^^
Electronic Design & Tools oo ) Philips Research Labs
Building WAY 3.23 =x= \ (e-mail address removed)
Prof. Holstlaan 4 (WAY31) | \ tel. +31 40 27 45334
5656 AA Eindhoven /|__ \ tfx. +31 40 27 44626
The Netherlands (____)_/ http://www.kenter.demon.nl/

Famous last words: Segmentation Fault (core dumped)

 

[Papadopoulos Giannis]

You snipped: "There's also the possibility of mixed endian."
Again,
there are more choices allowed by the C standard
than just big or little.

Is there currently a machine that supports both?? Even if it is some
kind of a mixed endian, the general case is that only the integer
endianess is important - though, it depends on the case...

If your int representation has padding bits,
then it's possible that one of the bytes might have a set padding
bit which is not part of the value of ((int)1),
but which shows up during byte examination.

I do not know a machine that uses padding bits - plz provide more info...


--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[Papadopoulos Giannis]

And by the way, if sizeof(char) == sizeof(int) on your implementation, the
output isn't going to be very useful anyway (remember, a char is not
necessarily
a byte!) Or is that what you were getting at...

and if char is not a byte, then what can we use as a byte??

--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[Mark McIntyre]

(remember, a char is not necessarily a byte!)

Well, actually it /is/ necessarily a byte, but its not necessarily 8 bits
wide, which is what I think you meant.

(FYI the C standard defines byte such that its a synonym for char (section
3.6). Its only 'modern' slack usage that defines it as a synonym for
octet).

 

[Mark McIntyre]

and if char is not a byte, then what can we use as a byte??

its ok, a char /is/ a byte, by definition.

 

[E. Robert Tisdale]

Well, actually it /is/ necessarily a byte,

Not exactly.
A byte is a *size* and *not* a data type.

sizeof(char) = 1 byte

but its not necessarily 8 bits wide, which is what I think you meant.

(FYI the C standard defines byte such that its a synonym for char
(section 3.6).
Its only 'modern' slack usage that defines it as a synonym for octet).

Meaning that an octet is an 8-bit byte.

 

[Keith Thompson]

Incidentally, the mathematical symbol for XOR is often a plus sign
with a circle around it, to indicate that it behaves like addition
in the field (Z_2)^n. I have no idea where the idea of using ^ for
XOR came from, except that ^ kind of looks like the lower half of a
superscript "X".

I suspect it was one of the few ASCII punctuation marks left over when
C (or one of its predecessors) was being designed.

 

[Keith Thompson]

And by the way, if sizeof(char) == sizeof(int) on your
implementation, the output isn't going to be very useful anyway
(remember, a char is not necessarily a byte!) Or is that what you
were getting at...

(It's already been pointed out that a char *is* necessarily a byte,
though it's not necessarily 8 bits.)

If sizeof(char) == sizeof(int), the type int has no meaningful
endianness. Endianness is about the ordering of bytes within a larger
type.

On the other hand, a system with sizeof(int)==1 could have, say,
sizeof(long)==2; in that case, the endianness of type long is
meaningful.

 

[Keith Thompson]

Not exactly.
A byte is a *size* and *not* a data type.

sizeof(char) = 1 byte

The term "byte" refers to a region of data storage.

The standard's definition (3.6) is:

byte

addressable unit of data storage large enough to hold any member
of the basic character set of the execution environment

NOTE 1 It is possible to express the address of each individual
byte of an object uniquely.

NOTE 2 A byte is composed of a contiguous sequence of bits, the
number of which is implementation-defined. The least significant
bit is called the low-order bit; the most significant bit is
called the high-order bit.

The term is also commonly used to refer to the size of such a region
(CHAR_BIT bits) or to an appropriate type, as in:

typedef unsigned char BYTE;

[snip]

Meaning that an octet is an 8-bit byte.

No, meaning that an octet is an 8-bit quantity. On a system where
CHAR_BIT==16, an octet is half a byte.

 

[E. Robert Tisdale]

Keith Thompson wrote:

If sizeof(char) == sizeof(int),
the type int has no meaningful endianness.

Endianness is about the ordering of bytes within a larger type.

Nonsense!

Suppose that two machine architectures with different byte sizes
need to communicate with each other (over ethernet for example).

 

[Keith Thompson]

Is there currently a machine that supports both?? Even if it is some
kind of a mixed endian, the general case is that only the integer
endianess is important - though, it depends on the case...

Some hardware (e.g., the DEC^H^H^HCompaq^H^H^H^H^H^HHP Alpha) can
support either big-endian or little-endian, though usually a
consistent choice is made for a given OS.

I think that the PDP-11, a 16-bit system, uses (used?) one endianness
for 8-bit bytes within a 16-bit word, and the other for 16-bit words
within a 32-bit long word. Thus the 32-bit long word representing the
value 0x01020304 might contain the bytes 0x02, 0x01, 0x04, and 0x03
(or perhaps the opposite). I'm not at all sure of this.

 

[E. Robert Tisdale]

Some hardware (e.g., the DEC^H^H^HCompaq^H^H^H^H^H^HHP Alpha)

Motorola/IBM PowerPC

 

[Papadopoulos Giannis]

Keith Thompson wrote:




Nonsense!

Suppose that two machine architectures with different byte sizes
need to communicate with each other (over ethernet for example).

All modern OSes have a function to convert to big endian the port
number.. And in general all systems use big endian for communicating
over any network...

Keith is all ok.. On the other hand I do not understand your objection...

--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

 

[E. Robert Tisdale]

All modern OSes have a function
to convert to big endian the port number..
And, in general, all systems use big endian
for communicating over any network...

Yes. Network byte order is bigendian.

Keith is all ok..

Not *all* ok.

On the other hand I do not understand your objection...

Keith missed the fact that byte order also has meaning
with respect to the network and other machines.
His CPU can't even talk to the UART without considering byte order.

 

[Keith Thompson]

Nonsense!

Suppose that two machine architectures with different byte sizes
need to communicate with each other (over ethernet for example).

Let's assume we have a machine where CHAR_BIT==32 and sizeof(int)==1,
and it needs to communicate with a machine with 8-bit bytes. (Feel
free to assume a 2's-complement representation with no padding bits.)
Assume that the communications protocol is defined in terms of
transmitting an octet at a time in a defined order. (I'm not familiar
with the Ethernet protocol, so I won't use it as an exmample.) Then
*something* on the sending machine needs to break each 32-bit int down
into four octets. Since a 32-bit int on this machine is not
inherently composed of 8-bit chunks, the endianness of this conversion
is a matter of choice, and has nothing to do with any inherent
property of the type int.

Suppose we have a machine with 8-bit bytes that wants to communicate
over a protocol that sends one 4-bit nybble at a time. We have to
decide which nybble to send first. This decision has nothing to do
with any inherent endianness of a single 8-bit byte.

Again, as I said earlier, "the type int has no meaningful endianness"
for such a system; you can impose whatever endianness you need for a
given interface.

 

[pete]

Papadopoulos Giannis wrote:

I do not know a machine that uses padding bits

Me neither.

- plz provide more info...

http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/

 

[Dan Pop]

Why should he? That is a serious question. He doesn't need
stdio.h either.

Then, where is NULL defined? Have I ever recommended engaging the brain
before posting? ;-)

Dan

 

[Dan Pop]

You snipped: "There's also the possibility of mixed endian."
Again,
there are more choices allowed by the C standard
than just big or little.

The real world has excluded them, though, otherwise the terms big endian
and little endian wouldn't be that popular.

The most notable machine being neither little endian nor big endian
was the PDP-11. A long consisted of two words stored in big endian order.
Each word consisted of two bytes, stored in little endian order.

Dan