Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > undefined behavior or not undefined behavior? That is the question

Reply
Thread Tools

undefined behavior or not undefined behavior? That is the question

 
 
Mantorok Redgormor
Guest
Posts: n/a
 
      02-08-2004
#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
 
Reply With Quote
 
 
 
 
Papadopoulos Giannis
Guest
Posts: n/a
 
      02-08-2004
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)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.
 
Reply With Quote
 
 
 
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      02-08-2004

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
 
Reply With Quote
 
Papadopoulos Giannis
Guest
Posts: n/a
 
      02-08-2004
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)(Big);return 0;}

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.
 
Reply With Quote
 
Malcolm
Guest
Posts: n/a
 
      02-08-2004

"Papadopoulos Giannis" <(E-Mail Removed)> 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.



 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      02-08-2004
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)(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
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      02-08-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>


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

--
Chuck F ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!


 
Reply With Quote
 
Mantorok Redgormor
Guest
Posts: n/a
 
      02-08-2004
"Arthur J. O'Dwyer" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed) du>...
> 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

 
Reply With Quote
 
Leor Zolman
Guest
Posts: n/a
 
      02-08-2004
On 8 Feb 2004 07:20:10 -0800, http://www.velocityreviews.com/forums/(E-Mail Removed) (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
(E-Mail Removed)
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
 
Reply With Quote
 
Malcolm
Guest
Posts: n/a
 
      02-08-2004

"pete" <(E-Mail Removed)> 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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
free void*-- why not undefined behavior? Kavya C Programming 5 10-30-2006 05:38 PM
Q: reinterpret_cast with undefined behavior? Jakob Bieling C++ 13 05-02-2005 04:46 AM
please explain why this is Undefined Behavior REH C++ 25 03-29-2005 10:19 PM
Is it an undefined behavior in C++ Standard? aka C++ 10 03-15-2005 09:21 AM



Advertisments