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

undefined behavior or not undefined behavior? That is the question

P: n/a
#include <stdio.h>

struct foo { int example; struct bar *ptr; };

int main(void)
{
struct foo baz;
baz.ptr = NULL; /* Undefined behavior? */

return 0;
}
My second question is not related to undefined behavior.
I read that bitwise AND is equivalent to
"Multiplication modulus two" They made some notation
with something that looked like two Zs'

Anyone familiar with that?

However:

printf("%d\n", 10 & 42);

printf("%d\n", (10 * 42) % 2);

most certainly differ.

but they used ^ for AND and said:

a * b (mod 2) = a ^ b

--
nethlek
Nov 14 '05 #1
Share this Question
Share on Google+
66 Replies


P: n/a
Mantorok Redgormor wrote:
#include <stdio.h>

struct foo { int example; struct bar *ptr; };

int main(void)
{
struct foo baz;
baz.ptr = NULL; /* Undefined behavior? */

return 0;
}

first of all define struct bar nad #include <stdlib.h>

why should assignment of a pointer to NULL should be undefined
My second question is not related to undefined behavior.
I read that bitwise AND is equivalent to
"Multiplication modulus two" They made some notation
with something that looked like two Zs'

I don't think this is right... Am I missing something?
but they used ^ for AND and said:

a * b (mod 2) = a ^ b
the ^ is not AND operator, it is the XOR operator...
and it doesn't seem to work either...
--
nethlek


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

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.
Nov 14 '05 #2

P: n/a

On Sun, 8 Feb 2004, Papadopoulos Giannis wrote:

Mantorok Redgormor wrote:
#include <stdio.h>

struct foo { int example; struct bar *ptr; };

int main(void)
{
struct foo baz;
baz.ptr = NULL; /* Undefined behavior? */

return 0;
}

first of all define struct bar nad #include <stdlib.h>


Unnecessary and unnecessary, respectively. A definition for
'struct bar' is not needed in order to declare a pointer to said
struct. And NULL is defined in <stdio.h>, among many other places,
AFAIR.
why should assignment of a pointer to NULL should be undefined
Who knows /what/ was running through Mantorok's head? [To
the OP: Why not /tell/ us why you think such-and-such should be
undefined, or defined, rather than just posting a random text
file and letting us run it through a compiler for you? How do
you expect to learn anything this way?]

My second question is not related to undefined behavior.
I read that bitwise AND is equivalent to
"Multiplication modulus two" They made some notation
with something that looked like two Zs'


I don't think this is right... Am I missing something?


Yes, but I have no idea what, because, like the OP, you didn't
give any reasons for your statement that you "don't think this
is right."
Bitwise AND is exactly isomorphic to multiplication in the
field of the integers modulo 2. Compare:

0 & 0 = 0 0 * 0 = 0
0 & 1 = 0 0 * 1 = 0
1 & 0 = 0 1 * 0 = 0
1 & 1 = 1 1 * 1 = 1

See? Same thing.
but they used ^ for AND


Do you mean "they" (perhaps a math textbook?) used the
logical AND operator, looking something like an upside-down wide V,
or the exponentiation operator "up-arrow," displayed on a computer
screen as "^"?
In C, logical AND is spelled &&, exponentiation is spelled "pow"
(after #including <math.h>), and the operator spelled ^ is pronounced
"bitwise XOR."

[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.]

-Arthur
Nov 14 '05 #3

P: n/a
Arthur J. O'Dwyer wrote:
On Sun, 8 Feb 2004, Papadopoulos Giannis wrote:
Mantorok Redgormor wrote:
#include <stdio.h>

struct foo { int example; struct bar *ptr; };

int main(void)
{
struct foo baz;
baz.ptr = NULL; /* Undefined behavior? */

return 0;
}

first of all define struct bar nad #include <stdlib.h>

Unnecessary and unnecessary, respectively. A definition for
'struct bar' is not needed in order to declare a pointer to said
struct. And NULL is defined in <stdio.h>, among many other places,
AFAIR.


Hmm, whenever I used NULL, I used it with malloc() calls.. So I thought
they were both in stdlib.h...
My second question is not related to undefined behavior.
I read that bitwise AND is equivalent to
"Multiplication modulus two" They made some notation
with something that looked like two Zs'


I don't think this is right... Am I missing something?

Yes, but I have no idea what, because, like the OP, you didn't
give any reasons for your statement that you "don't think this
is right."
Bitwise AND is exactly isomorphic to multiplication in the
field of the integers modulo 2. Compare:

0 & 0 = 0 0 * 0 = 0
0 & 1 = 0 0 * 1 = 0
1 & 0 = 0 1 * 0 = 0
1 & 1 = 1 1 * 1 = 1

See? Same thing.


Maybe for 1 and 0 (as integers)... elsewhere is unapplicable...
[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.]


I am only trying to find if the machine is big endian or little endian..
After 0.29 s in google I found
http://www.treedragon.com/ged/fe/no/endianess.htm

And why should *(char*)&v invoke undefined behaviour? I am only doing this

union {
int v;
char c[4]; /* assuming 32-bit machine */
};

So v in big endian is 0x00 0x00 0x00 0x01 and in little endian is 0x01
0x00 0x00 0x00.

Using c[0] (or equivalently *(char*)&v) one can find endianess.. Still,
this doesn't work on machines with 8-bit integers...
--
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.
Nov 14 '05 #4

P: n/a
Papadopoulos Giannis wrote:

Arthur J. O'Dwyer wrote: Hmm, whenever I used NULL, I used it with malloc() calls..
So I thought they were both in stdlib.h...
They are both in stdlib.h. All of the macros,
which are needed to describe any standard library function,
are defined in the header corresponding to the function.
Therefore, all standard library headers which have the prototype
for any function capable of returning NULL, define NULL too.
malloc takes a size_t argument,
so you can assume that size_t is defined in stdlib.h, also.
I am only trying to find if the machine is big
endian or little endian..
There's also the possibility of mixed endian.
After 0.29 s in google I found
http://www.treedragon.com/ged/fe/no/endianess.htm

And why should *(char*)&v invoke undefined behaviour? /* assuming 32-bit machine */ So v in big endian is 0x00 0x00 0x00 0x01 and in little endian is 0x01
0x00 0x00 0x00.

Using c[0] (or equivalently *(char*)&v)
one can find endianess.. Still,
this doesn't work on machines with 8-bit integers...
There are none in C.
type int, has exactly 1 sign bit and at least 15 value bits, always.
#include <stdio.h>
#define p(s) printf(#s" endian")
int main(void){int v=1;*(char*)&v?p(Little):p(Big);return 0;}


We don't generally assume a 32 bit machine, here.
If int has any padding, it's possible that *(char*)&v
might be signed and also a trap representation of negative zero.

--
pete
Nov 14 '05 #5

P: n/a
Papadopoulos Giannis wrote:
Mantorok Redgormor wrote:
#include <stdio.h>

struct foo { int example; struct bar *ptr; };

int main(void)
{
struct foo baz;
baz.ptr = NULL; /* Undefined behavior? */

return 0;
}


first of all define struct bar nad #include <stdlib.h>


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

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #6

P: n/a
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi**********************************@chlorop rene.ww.andrew.cmu.edu>...
On Sun, 8 Feb 2004, Papadopoulos Giannis wrote:

Mantorok Redgormor wrote:
#include <stdio.h>

struct foo { int example; struct bar *ptr; };

int main(void)
{
struct foo baz;
baz.ptr = NULL; /* Undefined behavior? */

return 0;
}

first of all define struct bar nad #include <stdlib.h>


Unnecessary and unnecessary, respectively. A definition for
'struct bar' is not needed in order to declare a pointer to said
struct. And NULL is defined in <stdio.h>, among many other places,
AFAIR.
why should assignment of a pointer to NULL should be undefined


Who knows /what/ was running through Mantorok's head? [To
the OP: Why not /tell/ us why you think such-and-such should be
undefined, or defined, rather than just posting a random text
file and letting us run it through a compiler for you? How do
you expect to learn anything this way?]


well if an lvalue does not designate an object
then it invokes undefined behavior.

you need type information for a type to not be
an incomplete type.

until then, the type of something is incomplete and
does not refer to an object, right?

so when you have a struct declaration of:

struct foo { int example; struct bar *ptr; };

and then supply your definition:

struct foo baz;

baz is an actual object, example is an actual object
but what about "ptr" ? it is not a valid pointer object
right?

so it cannot hold:

baz.ptr = NULL; /* can't hold the value of NULL? */

and also under such a circumstance, why is this even
allowed in this regard?

If the type definition is never given for "struct bar"
then the type may never be completed
so in essence you end up with a completely useless
incomplete type in this regard.

it would seem logical for a compiler
to have to issue some type of diagnostic
if it knows the type is never completed.
My second question is not related to undefined behavior.
I read that bitwise AND is equivalent to
"Multiplication modulus two" They made some notation
with something that looked like two Zs'
I don't think this is right... Am I missing something?


Yes, but I have no idea what, because, like the OP, you didn't
give any reasons for your statement that you "don't think this
is right."
Bitwise AND is exactly isomorphic to multiplication in the
field of the integers modulo 2. Compare:

0 & 0 = 0 0 * 0 = 0
0 & 1 = 0 0 * 1 = 0
1 & 0 = 0 1 * 0 = 0
1 & 1 = 1 1 * 1 = 1

See? Same thing.


yeah, sorry. I was thinking modulus % operator
when what it meant was in base2.

but they used ^ for AND


Do you mean "they" (perhaps a math textbook?) used the
logical AND operator, looking something like an upside-down wide V,
or the exponentiation operator "up-arrow," displayed on a computer
screen as "^"?
In C, logical AND is spelled &&, exponentiation is spelled "pow"
(after #including <math.h>), and the operator spelled ^ is pronounced
"bitwise XOR."

[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.]

-Arthur

Nov 14 '05 #7

P: n/a
On 8 Feb 2004 07:20:10 -0800, ne*****@tokyo.com (Mantorok Redgormor)
wrote:
so when you have a struct declaration of:

struct foo { int example; struct bar *ptr; };

and then supply your definition:

struct foo baz;

baz is an actual object, example is an actual object
but what about "ptr" ? it is not a valid pointer object
right?

Note how you switched terminology when you got to "ptr"? If you'd gone
on to say, "...it is not an actual object, right"? You'd have been
wrong, because it is. But it is not a valid pointer.

For a pointer,
SOMETHING *p;
p can represent an lvalue, and so can *p. But they're distinct.
-leor
so it cannot hold:

baz.ptr = NULL; /* can't hold the value of NULL? */

and also under such a circumstance, why is this even
allowed in this regard?

If the type definition is never given for "struct bar"
then the type may never be completed
so in essence you end up with a completely useless
incomplete type in this regard.

it would seem logical for a compiler
to have to issue some type of diagnostic
if it knows the type is never completed.
> > My second question is not related to undefined behavior.
> > I read that bitwise AND is equivalent to
> > "Multiplication modulus two" They made some notation
> > with something that looked like two Zs'
>
> I don't think this is right... Am I missing something?


Yes, but I have no idea what, because, like the OP, you didn't
give any reasons for your statement that you "don't think this
is right."
Bitwise AND is exactly isomorphic to multiplication in the
field of the integers modulo 2. Compare:

0 & 0 = 0 0 * 0 = 0
0 & 1 = 0 0 * 1 = 0
1 & 0 = 0 1 * 0 = 0
1 & 1 = 1 1 * 1 = 1

See? Same thing.


yeah, sorry. I was thinking modulus % operator
when what it meant was in base2.

> > but they used ^ for AND


Do you mean "they" (perhaps a math textbook?) used the
logical AND operator, looking something like an upside-down wide V,
or the exponentiation operator "up-arrow," displayed on a computer
screen as "^"?
In C, logical AND is spelled &&, exponentiation is spelled "pow"
(after #including <math.h>), and the operator spelled ^ is pronounced
"bitwise XOR."

[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.]

-Arthur


Leor Zolman
BD Software
le**@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html
Nov 14 '05 #8

P: n/a
Leor Zolman wrote:

On 8 Feb 2004 07:20:10 -0800, ne*****@tokyo.com (Mantorok Redgormor)
wrote:
so when you have a struct declaration of:

struct foo { int example; struct bar *ptr; };

and then supply your definition:

struct foo baz;

baz is an actual object, example is an actual object
but what about "ptr" ? it is not a valid pointer object
right?


Note how you switched terminology when you got to "ptr"? If you'd gone
on to say, "...it is not an actual object, right"? You'd have been
wrong, because it is. But it is not a valid pointer.

For a pointer,
SOMETHING *p;
p can represent an lvalue, and so can *p. But they're distinct.
-leor

Hello Leor. Welcome to the fray. I remember you as the author of BDS C
for CP/M 80 a quarter century ago. Or is it only 20 years? Or do I have
you mixed up with the other Leor Zolman? :)
--
Joe Wright http://www.jw-wright.com
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 14 '05 #9

P: n/a

"Papadopoulos Giannis" <ip******@inf.uth.gr> wrote in message
Hmm, whenever I used NULL, I used it with malloc() calls.. So I
thought they were both in stdlib.h...
NULL is defined in lots of headers for convenience.
And why should *(char*)&v invoke undefined behaviour? I am only
doing this
The answer is that there might be trap representations. For instance, a
Communist computer manufacturer could declare the numer 36 to be an illegal
representation. Every time the computer detects it, it could abort with an
error "Capitalist user detected".
union {
int v;
char c[4]; /* assuming 32-bit machine */
};

So v in big endian is 0x00 0x00 0x00 0x01 and in little endian is 0x01
0x00 0x00 0x00.

Using c[0] (or equivalently *(char*)&v) one can find endianess.. Still,
this doesn't work on machines with 8-bit integers...

No you are not. Unions are designed to save space, but there is guarantee
about layout. I don't actually know any trap architectures, but probably the
layout would be as you say, and a trap would result as you illegally access
a char after writing an int.

Nov 14 '05 #10

P: n/a

"pete" <pf*****@mindspring.com> wrote in message
Still, this doesn't work on machines with 8-bit integers...


There are none in C.
type int, has exactly 1 sign bit and at least 15 value bits, always.

Though I once had a small embedded system that worked on 8-bit ints, so the
requirements of the standard and actual practise don't always match.
Nov 14 '05 #11

P: n/a
Malcolm wrote:
"pete" <pf*****@mindspring.com> wrote in message
Still, this doesn't work on machines with 8-bit integers...


There are none in C.
type int, has exactly 1 sign bit and at least 15 value bits, always.


Though I once had a small embedded system that worked on 8-bit ints, so the
requirements of the standard and actual practise don't always match.


Any implementation that has CHAR_BIT == 8 has 8-bit integers. No C
implementation is *required* to have 8-bit integers, but any *may*. That
no flavor of int can fit into 8 bits is a red herring.
It is also false that
type int, has exactly 1 sign bit and at least 15 value bits, always.

Your implementation does not define the C language.

--
Martin Ambuhl
Nov 14 '05 #12

P: n/a
Leor Zolman <le**@bdsoft.com> wrote in message news:<lk********************************@4ax.com>. ..
On 8 Feb 2004 07:20:10 -0800, ne*****@tokyo.com (Mantorok Redgormor)
wrote:
so when you have a struct declaration of:

struct foo { int example; struct bar *ptr; };

and then supply your definition:

struct foo baz;

baz is an actual object, example is an actual object
but what about "ptr" ? it is not a valid pointer object
right?

Note how you switched terminology when you got to "ptr"? If you'd gone
on to say, "...it is not an actual object, right"? You'd have been
wrong, because it is. But it is not a valid pointer.


I think you missed something.
"ptr" can never be an object since
its type definition is never complete.

so it remains an incomplete type.

though I can't find the relevant sections in the standard
that say that at this time.

--
nethlek
For a pointer,
SOMETHING *p;
p can represent an lvalue, and so can *p. But they're distinct.
-leor
so it cannot hold:

baz.ptr = NULL; /* can't hold the value of NULL? */

and also under such a circumstance, why is this even
allowed in this regard?

If the type definition is never given for "struct bar"
then the type may never be completed
so in essence you end up with a completely useless
incomplete type in this regard.

it would seem logical for a compiler
to have to issue some type of diagnostic
if it knows the type is never completed.

> > My second question is not related to undefined behavior.
> > I read that bitwise AND is equivalent to
> > "Multiplication modulus two" They made some notation
> > with something that looked like two Zs'
>
> I don't think this is right... Am I missing something?

Yes, but I have no idea what, because, like the OP, you didn't
give any reasons for your statement that you "don't think this
is right."
Bitwise AND is exactly isomorphic to multiplication in the
field of the integers modulo 2. Compare:

0 & 0 = 0 0 * 0 = 0
0 & 1 = 0 0 * 1 = 0
1 & 0 = 0 1 * 0 = 0
1 & 1 = 1 1 * 1 = 1

See? Same thing.


yeah, sorry. I was thinking modulus % operator
when what it meant was in base2.


> > but they used ^ for AND

Do you mean "they" (perhaps a math textbook?) used the
logical AND operator, looking something like an upside-down wide V,
or the exponentiation operator "up-arrow," displayed on a computer
screen as "^"?
In C, logical AND is spelled &&, exponentiation is spelled "pow"
(after #including <math.h>), and the operator spelled ^ is pronounced
"bitwise XOR."

[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.]

-Arthur


Leor Zolman
BD Software
le**@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

Nov 14 '05 #13

P: n/a
On 8 Feb 2004 21:35:33 -0800, ne*****@tokyo.com (Mantorok Redgormor)
wrote:
>
>struct foo { int example; struct bar *ptr; };
>
>and then supply your definition:
>
>struct foo baz;
>
>baz is an actual object, example is an actual object
>but what about "ptr" ? it is not a valid pointer object
>right?
>
Note how you switched terminology when you got to "ptr"? If you'd gone
on to say, "...it is not an actual object, right"? You'd have been
wrong, because it is. But it is not a valid pointer.


I think you missed something.
"ptr" can never be an object since
its type definition is never complete.


The point I was trying to make is that "ptr", being a pointer, is
itself just like a "primitive type". It cannot be incomplete. However,
it can be defined to /point/ to something whose type is still
incomplete at the time of ptr's definition.

so it remains an incomplete type.
"struct bar" is the incomplete type, /not/ ptr.

though I can't find the relevant sections in the standard
that say that at this time.


Just /think/ about it. Doesn't the compiler have all the information
it needs to place ptr into a fixed location in memory of known size?
It is the size of a pointer; whatever that is, it is /known/.
-leor
Nov 14 '05 #14

P: n/a

On Mon, 9 Feb 2004, Dik T. Winter wrote:

Papadopoulos Giannis <ip******@inf.uth.gr> writes:
Mantorok Redgormor wrote: ...
My second question is not related to undefined behavior.
I read that bitwise AND is equivalent to
"Multiplication modulus two" They made some notation
with something that looked like two Zs'


I don't think this is right... Am I missing something?


It was probably in a text using mathematical notation. It is
equivalent to pointwise multiplication in an n-dimensional
vector space over Z_2. Or (to be more precise) an operation
from Z_2<sup>n * Z_2<sup>n -> Z_2<sup>n (where _ means subscript
and <sup> means superscript).


Nitpick: I would have said it was an operation *from*
(Z_2)^n * (Z_2)^n *to* (Z_2)^n, or an operation *in*
(Z_2)^n * (Z_2)^n -> (Z_2)^n. I don't know if that's a widely
used mode of speech, but it makes more sense to me, syntactically
speaking.
> > but they used ^ for AND and said:
> >
> > a * b (mod 2) = a ^ b

>
> the ^ is not AND operator, it is the XOR operator...
> and it doesn't seem to work either...


Not in mathematical notation. There ^ indicates AND.


As I said (and you snipped), ^ in mathematics quite often
indicates exponentiation, and *never* logical AND. The usual
symbol for logical AND is a sort of inverted V, as seen here:
http://mathworld.wolfram.com/aimg1694.gif
which is not the same symbol as the caret or up-arrow, as seen here:
"A ^ B"
Well, okay, I couldn't find any images of that symbol. But you
can get both of them in LaTeX with \land and \^{}, respectively.

How ^
came to be XOR in C is interesting, because it is AND in the
Algol languages.


Same objection as above. The Algol language described in the one
book I own on the subject uses the inverted-V AND operator seen in
the image above, IIRC.
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". :-)

-Arthur

Nov 14 '05 #15

P: n/a
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@chloropr ene.ww.andrew.cmu.edu...
....
[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.]

--
Peter
Nov 14 '05 #16

P: n/a
Papadopoulos Giannis <ip******@inf.uth.gr> wrote:
pete wrote:
Papadopoulos Giannis wrote:
Hmm, whenever I used NULL, I used it with malloc() calls..
So I thought they were both in stdlib.h...
They are both in stdlib.h. All of the macros,
which are needed to describe any standard library function,
are defined in the header corresponding to the function.

<snip>
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
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc : http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
acllc-c++ faq : http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #17

P: n/a
Papadopoulos Giannis wrote:

pete wrote:
Papadopoulos Giannis wrote:
Arthur J. O'Dwyer wrote: Hmm, whenever I used NULL, I used it with malloc() calls..
So I thought they were both in stdlib.h...

They are both in stdlib.h. All of the macros,
which are needed to describe any standard library function,
are defined in the header corresponding to the function.
Therefore, all standard library headers which have the prototype
for any function capable of returning NULL, define NULL too.
malloc takes a size_t argument,
so you can assume that size_t is defined in stdlib.h, also.

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

We don't generally assume a 32 bit machine, here.
If int has any padding, it's possible that *(char*)&v
might be signed and also a trap representation of negative zero.


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:
/* assuming 32-bit machine */

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.

--
pete
Nov 14 '05 #18

P: n/a
Peter Nilsson wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
news:Pi**********************************@chloropr ene.ww.andrew.cmu.edu...
...
[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= \ ar**********@philips.com
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)

Nov 14 '05 #19

P: n/a
pete wrote:
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...
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.


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):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.
Nov 14 '05 #20

P: n/a
Arjan Kenter wrote:
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):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.
Nov 14 '05 #21

P: n/a
On Mon, 09 Feb 2004 15:47:13 +0100, in comp.lang.c , Arjan Kenter
<ar**********@philips.com.dontspamme> wrote:
(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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #22

P: n/a
On Mon, 09 Feb 2004 19:26:03 +0200, in comp.lang.c , Papadopoulos Giannis
<ip******@inf.uth.gr> wrote:
Arjan Kenter wrote:
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??


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

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #23

P: n/a
Mark McIntyre wrote:
Arjan Kenter wrote:
(remember, a char is not necessarily a byte!)
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.

Nov 14 '05 #24

P: n/a
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
[...]
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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #25

P: n/a
Arjan Kenter <ar**********@philips.com.dontspamme> writes:
[...]
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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #26

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
Mark McIntyre wrote:
Arjan Kenter wrote:
(remember, a char is not necessarily a byte!) Well, actually it /is/ necessarily a byte,


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #27

P: n/a
Papadopoulos Giannis <ip******@inf.uth.gr> writes:
pete wrote:
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...


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #28

P: n/a
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).
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.


Nov 14 '05 #29

P: n/a
Keith Thompson wrote:
Some hardware (e.g., the DEC^H^H^HCompaq^H^H^H^H^H^HHP Alpha)
Motorola/IBM PowerPC
can support either big-endian or little-endian,


Nov 14 '05 #30

P: n/a
E. Robert Tisdale wrote:
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).


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):p(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.
Nov 14 '05 #31

P: n/a
Papadopoulos Giannis wrote:
E. Robert Tisdale wrote:
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).


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.

Nov 14 '05 #32

P: n/a
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
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).


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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #33

P: n/a
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/

--
pete
Nov 14 '05 #34

P: n/a
In <40**************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Papadopoulos Giannis wrote:
Mantorok Redgormor wrote:
> #include <stdio.h>
>
> struct foo { int example; struct bar *ptr; };
>
> int main(void)
> {
> struct foo baz;
> baz.ptr = NULL; /* Undefined behavior? */
>
> return 0;
> }
>


first of all define struct bar nad #include <stdlib.h>


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
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #35

P: n/a
In <40***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #36

P: n/a
In <40**************@jpl.nasa.gov> "E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:
Keith Thompson wrote:
Some hardware (e.g., the DEC^H^H^HCompaq^H^H^H^H^H^HHP Alpha)


Motorola/IBM PowerPC


Practically any new architecture designed for general computing purposes
is bi-endian: MIPS, SPARC(v9), Alpha, PPC, Itanium.

MIPS was/is used in big endian mode by SGI, but was used in little endian
mode by DEC.

Alpha was used in little endian mode by DEC and in big endian mode by
Cray.

Itanium is used in big endian mode by HP and in little endian mode by
everyone else.

PPC is used in big endian mode by IBM and Apple, but it was used in little
endian mode during the short lived Windows NT on PPC project.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #37

P: n/a
In <41**************************@posting.google.com > ne*****@tokyo.com (Mantorok Redgormor) writes:
well if an lvalue does not designate an object
then it invokes undefined behavior.
In your example, the lvalue designated an object.
you need type information for a type to not be
an incomplete type.


OTOH, a pointer to an incomplete type is a complete type. Take pointers
to void as a canonical example.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #38

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
[...]
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.


I agree: they've probably used all the ones with obvious meanings
and tried to do the best with what was left: ^, ~, !, %, ?, :.

I've never understood why @ and $ were left unused, while & and * have
been overloaded. @ would have done nicely instead of unary & and $
instead of unary *.

` was used in the earliest C versions, for a purpose with little relevance
outside the BTL (GECOS string literals).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #39

P: n/a
Dan Pop wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes: [ snippeee ]I suspect it was one of the few ASCII punctuation marks left over when
C (or one of its predecessors) was being designed.

I agree: they've probably used all the ones with obvious meanings
and tried to do the best with what was left: ^, ~, !, %, ?, :.

I've never understood why @ and $ were left unused, while & and * have
been overloaded. @ would have done nicely instead of unary & and $
instead of unary *.


Maybe K and R didn't want to use $ for fear that people outside the USA
would get into trouble (did traditional British keyboards have dollar signs
or pound signs? Dutch typewriters had both dollar and 'florin' signs).

Btw, Apollo C allowed $ in identifiers, library functions were often
named <lib>_$func where <lib> was the name of your library.
` was used in the earliest C versions, for a purpose with little relevance
outside the BTL (GECOS string literals).


--
ir. H.J.H.N. Kenter ^^
Electronic Design & Tools oo ) Philips Research Labs
Building WAY 3.23 =x= \ ar**********@philips.com
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)

Nov 14 '05 #40

P: n/a
Dan Pop wrote:
CBFalconer <cb********@yahoo.com> writes:
Papadopoulos Giannis wrote:
Mantorok Redgormor wrote:

> #include <stdio.h>
>
> struct foo { int example; struct bar *ptr; };
>
> int main(void)
> {
> struct foo baz;
> baz.ptr = NULL; /* Undefined behavior? */
>
> return 0;
> }
>

first of all define struct bar nad #include <stdlib.h>


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


Cavil: I didn't say he didn't have to compensate. Replacing NULL
by 0 would suffice. I would have thought you capable of this
extension without detailed prompting :-)

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #41

P: n/a
In <40***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:
Dan Pop wrote:
CBFalconer <cb********@yahoo.com> writes:
>Papadopoulos Giannis wrote:
>> Mantorok Redgormor wrote:
>>
>> > #include <stdio.h>
>> >
>> > struct foo { int example; struct bar *ptr; };
>> >
>> > int main(void)
>> > {
>> > struct foo baz;
>> > baz.ptr = NULL; /* Undefined behavior? */
>> >
>> > return 0;
>> > }
>> >
>>
>> first of all define struct bar nad #include <stdlib.h>
>
> 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? ;-)


Cavil: I didn't say he didn't have to compensate.


If he had to compensate, then stdio.h *was needed*.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #42

P: n/a
On Tue, 10 Feb 2004 19:28:14 +0100, in comp.lang.c , Arjan Kenter
<ar**********@philips.com.dontspamme> wrote:
Dan Pop wrote:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:[ snippeee ]I suspect it was one of the few ASCII punctuation marks left over when
C (or one of its predecessors) was being designed.

I agree: they've probably used all the ones with obvious meanings
and tried to do the best with what was left: ^, ~, !, %, ?, :.

I've never understood why @ and $ were left unused, while & and * have
been overloaded. @ would have done nicely instead of unary & and $
instead of unary *.


Possibly because these characters didn't appear on the keyboard they were
using?
Also possibly because @ and $ were already overloaded with meaning in the
shell they were using.
Maybe K and R didn't want to use $ for fear that people outside the USA
would get into trouble (did traditional British keyboards have dollar signs
or pound signs? Dutch typewriters had both dollar and 'florin' signs).


For as long as I can recall, UK keyboards have had $ on shift-4. However
its certainly possible that other layouts might not have had it there.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #43

P: n/a
In article <c0**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop)
wrote:
In <40***********@mindspring.com> pete <pf*****@mindspring.com> writes:
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.


It is not just a matter of the architecture, it is also a matter of the
compiler. Many architectures in use today are based on 32 bit words. To
implement "long long" and "unsigned long long", the compiler typically
uses two 32 bit words. There is no technical reason why one of those
words should be first in memory and not the other, so 64 bit integers
could easily be mixed-endian on many current architectures.
Nov 14 '05 #44

P: n/a
In article <news:c0***********@sunnews.cern.ch>
Dan Pop <Da*****@cern.ch> writes:
I've never understood why @ and $ were left unused [in C]
"$" is perhaps harder to explain, but "@" was the V6 Unix line-kill
character (today usually ^U or ^X).
` was used in the earliest C versions, for a purpose with little relevance
outside the BTL (GECOS string literals).


Backquote for BCD literals for GECOS no doubt did not appear until
the GECOS compilers; I suspect it is debatable whether to call this
`earliest' versions of C. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #45

P: n/a
Da*****@cern.ch (Dan Pop) wrote in message news:<c0***********@sunnews.cern.ch>...
In <41**************************@posting.google.com > ne*****@tokyo.com (Mantorok Redgormor) writes:
well if an lvalue does not designate an object
then it invokes undefined behavior.


In your example, the lvalue designated an object.
you need type information for a type to not be
an incomplete type.


OTOH, a pointer to an incomplete type is a complete type. Take pointers
to void as a canonical example.

Dan


I mixed them up. I guess what I really wanted to ask
without providing any examples, since I am unsure
of where this would be applied. Is where does one
have a need for lvalues that are incomplete types?

--
nethlek
Nov 14 '05 #46

P: n/a
In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
In article <c0**********@sunnews.cern.ch>, Da*****@cern.ch (Dan Pop)
wrote:
In <40***********@mindspring.com> pete <pf*****@mindspring.com> writes:
>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.


It is not just a matter of the architecture, it is also a matter of the
compiler. Many architectures in use today are based on 32 bit words. To
implement "long long" and "unsigned long long", the compiler typically
uses two 32 bit words. There is no technical reason why one of those
words should be first in memory and not the other, so 64 bit integers
could easily be mixed-endian on many current architectures.


Show us one concrete example.

C implementors are usually not the most stupid people around and they
understand quite well the need for a consistent byte order among all the
types.

All the realistic examples of mixed endianness are historical, from an
age where the byte order issues were not as well understood as they have
been for the last quarter of century.

The PDP-11's successor, the VAX, had fixed that hardware design blunder
of its ancestor and was little endian over all the range of supported
types.

There are exactly two byte orders that have survived and, by no
coincidence, they are the two entirely consistent ones.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #47

P: n/a
In <41**************************@posting.google.com > ne*****@tokyo.com (Mantorok Redgormor) writes:
Da*****@cern.ch (Dan Pop) wrote in message news:<c0***********@sunnews.cern.ch>...
In <41**************************@posting.google.com > ne*****@tokyo.com (Mantorok Redgormor) writes:
>well if an lvalue does not designate an object
>then it invokes undefined behavior.


In your example, the lvalue designated an object.
>you need type information for a type to not be
>an incomplete type.


OTOH, a pointer to an incomplete type is a complete type. Take pointers
to void as a canonical example.

Dan


I mixed them up. I guess what I really wanted to ask
without providing any examples, since I am unsure
of where this would be applied. Is where does one
have a need for lvalues that are incomplete types?


Unless C99 has completely screwed the concept of lvalue, lvalues
cannot have incomplete types.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #48

P: n/a
In <c0*********@enews3.newsguy.com> Chris Torek <no****@torek.net> writes:
In article <news:c0***********@sunnews.cern.ch>
Dan Pop <Da*****@cern.ch> writes:
I've never understood why @ and $ were left unused [in C]


"$" is perhaps harder to explain, but "@" was the V6 Unix line-kill
character (today usually ^U or ^X).


And '#' was the erase character (IIRC), yet this didn't prevent its
usage in the language...
` was used in the earliest C versions, for a purpose with little relevance
outside the BTL (GECOS string literals).


Backquote for BCD literals for GECOS no doubt did not appear until
the GECOS compilers; I suspect it is debatable whether to call this
`earliest' versions of C. :-)


For easy to figure reasons, GECOS was one of the first porting targets.
By the time K&R1 went to print, ` was gone from the language.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #49

P: n/a
Dan Pop wrote:
Unless C99 has completely screwed the concept of lvalue, lvalues
cannot have incomplete types.


Unfortunately, they can:

An lvalue is an expression with an object type or an incomplete type
other than void; if an lvalue does not designate an object when it
is evaluated, the behavior is undefined.

I'm not sure why the second part is there: the only example of an
expression of incomplete type that I know is an array name where the
definition of the array is not in scope, and even that is
questionable.

Jeremy.
Nov 14 '05 #50

66 Replies

This discussion thread is closed

Replies have been disabled for this discussion.