473,320 Members | 1,612 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

About Union's question

Union un
{ int I;
char c[2];
}

main()
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);
}
What is the output results? Please explain in detail under.

Mar 30 '07 #1
32 1799
"" <wa*********@gmail.comschrieb im Newsbeitrag
news:11**********************@d57g2000hsg.googlegr oups.com...
#include <stdio.h>
Union un
union un
{ int I;
char c[2];
}
};
>
main()
int main(void)
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);
printf("%d\n",x.I);
return 0;
}
What is the output results? Please explain in detail under.
Lots of compiler errors and some warnings too, without the modifications
mentioned above. After having fixed these, on one of my machine the output
was 167838688, on another it was 1073807626.
Heavily depends in the implementation and machine architecture (big
endian/little endian)

Bye, Jojo
Mar 30 '07 #2
On 29 Mar 2007 23:24:56 -0700, "??????" <wa*********@gmail.comwrote:
>Union un
{ int I;
char c[2];
}

main()
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);
}
What is the output results? Please explain in detail under.
That code does not even compile with my compilers and should not
compile with yours. You should at least make an effort to insure that
your code compiles before submitting it to this newsgroup. Otherwise,
it can be difficult for anyone here to provide help to you.

Best regards
--
jay
Mar 30 '07 #3
On 3月30日, 下午3时46分, "JoachimSchmitz" <nospam.schm...@hp.comwrote:
"Íõ³¬·²" <wangchao...@gmail.comschrieb imNewsbeitragnews:11**********************@d57g200 0hsg.googlegroups.com...
#include <stdio.h>Union un
union un
{ int I;
char c[2];
}
};
main()
int main(void)
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);

printf("%d\n",x.I);
return 0;}
Thank you very much!I have something wrong with the procedure, as you
corrected by the right .

#include <stdio.h>
union un
{
int I;
char c[2];
}
int main(void)
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);

printf("%d\n",x.I);
return 0;
}
What is the output results? Please explain in detail under.

Lots of compiler errors and some warnings too, without the modifications
mentioned above. After having fixed these, on one of my machine the output
was 167838688, on another it was 1073807626.
Heavily depends in the implementation and machine architecture (big
endian/little endian)

Bye, Jojo
However, I still do not know how the compiler theory, Why the digital
output ? Depends what the outcome is different for each output?

Mar 30 '07 #4
??? said:
Union un
{ int I;
char c[2];
}

main()
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);
}
What is the output results?
It would be undefined because you're missing a header, except that it
won't compile because you're missing an x. And when you've added the x,
you still have to change i to I or I to i (either will do), and U to u.

Once you've done all that, the answer is "it depends".

All in all, I wouldn't bother if I were you.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 30 '07 #5
On 30 Mar 2007 00:02:33 -0700, "???" <wa*********@gmail.comwrote:
>On 3?30?, ??3?46?, "Joachim Schmitz" <nospam.schm...@hp.comwrote:
>"" <wangchao...@gmail.comschrieb im Newsbeitragnews:11**********************@d57g2000h sg.googlegroups.com...
#include <stdio.h>Union un
union un
{ int I;
char c[2];
}
};
main()
int main(void)
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);

printf("%d\n",x.I);
return 0;}
Thank you very much!I have something wrong with the procedure, as you
corrected by the right .
Your code still does not compile!
>#include <stdio.h>
union un
{
int I;
char c[2];
}
Change that to:

};
>

int main(void)
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);
That statement won't compile and requires a diagnostic. Just delete
it, since your following statement is correct.
>
printf("%d\n",x.I);
return 0;
}
I notice that you changed your posted name from "?????" to "???". I
have a feeling that if you change your posted name to simply "?", your
code will compile :)

All kidding aside, I'll tell you this ... in my 15+ years of
programming in C, I have never--not once--legitimately used a union,
because I've never needed to legitimately use one.

I've dealt with unions declared by compilers, which most compilers
inevitably seem to use (and I can live with that), and I've dealt with
fellow programmers who've declared unions (IMHO, unnecessarily). But
I've never found the need to legitimately use unions myself.

My advice to you is to understand unions, but to never use them in
your own code. In your example, I can tell you that you will not get
the results you expect on a lot of implementations, such as those in
which sizeof(int) != 2 (many if not most) and on those in which the
Endianness is Big when yours is Little or vice versa.

Best regards
--
jay
Mar 30 '07 #6
Union un
{ int I;
char c[2];
}
After "fixing" your code to make it compiled:

- int 4 bytes
- char 1 byte, char[2] - 2 bytes

so, after union is created it is filled with trash. Then you assign a values
but only to "char" components, the other two bytes of "int" component are
still filled with "trash". So final answer is "you will get unspecified
number".
Mar 30 '07 #7
"Marcin" <bl*@bla.plschrieb im Newsbeitrag
news:eu**********@atlantis.news.tpi.pl...
>Union un
{ int I;
char c[2];
}

After "fixing" your code to make it compiled:

- int 4 bytes
- char 1 byte, char[2] - 2 bytes

so, after union is created it is filled with trash. Then you assign a
values
but only to "char" components, the other two bytes of "int" component are
still filled with "trash". So final answer is "you will get unspecified
number".
Ah, yes, I missed that these other bytes still may be uninitialized... (on
an implementation with sizeof(int) != 2)

but
union un x;
x.I = 0;
x.c[0]=10;
x.c[1]=1;
printf("%d",x.I);

would still give some implementation/architecture dependant output.

Bye, Jojo
Mar 30 '07 #8
Marcin said:

<snip>
After "fixing" [the] code to make it compiled:

- int 4 bytes
- char 1 byte, char[2] - 2 bytes
What makes you think int is 4 bytes? It might be only one byte, or it
might be two bytes, or it might even be ninety-seven bytes.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 30 '07 #9

"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:Pd******************************@bt.com...
What makes you think int is 4 bytes? It might be only one byte, or it
might be two bytes, or it might even be ninety-seven bytes.
It can't be one byte.
One byte is defined as the size of an unsigned char, i.e. CHAR_BIT bits.
All 2^CHAR_BIT = UCHAR_MAX + 1 possible sequences of CHAR_BIT bits must be
valid unsigned char representations. Also, CHAR_BIT is required to be at
least 8.

An int must be able to represent all possible values of unsigned char, so
INT_MAX >= UCHAR_MAX.
Also, it must be able to represent all negative numbers down to -INT_MAX.
So, it must be able to represent at least 2*UCHAR_MAX - 1 values. To do
that, it must have at least ceil(log2(2*UCHAR_MAX - 1)) = CHAR_BIT + 1 bits.

Since any object must occupy an integer number of bytes, an int must have at
least 2 bytes.
Mar 30 '07 #10
Army1987 said:
>
"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:Pd******************************@bt.com...
>What makes you think int is 4 bytes? It might be only one byte, or it
might be two bytes, or it might even be ninety-seven bytes.

It can't be one byte.
Yes, it can.
One byte is defined as the size of an unsigned char, i.e. CHAR_BIT
bits. All 2^CHAR_BIT = UCHAR_MAX + 1 possible sequences of CHAR_BIT
bits must be valid unsigned char representations. Also, CHAR_BIT is
required to be at least 8.
All true.
An int must be able to represent all possible values of unsigned char,
Chapter and verse, please.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 30 '07 #11
"Army1987" <pl********@for.itwrote:
"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
What makes you think int is 4 bytes? It might be only one byte, or it
might be two bytes, or it might even be ninety-seven bytes.

It can't be one byte.
One byte is defined as the size of an unsigned char, i.e. CHAR_BIT bits.
All 2^CHAR_BIT = UCHAR_MAX + 1 possible sequences of CHAR_BIT bits must be
valid unsigned char representations. Also, CHAR_BIT is required to be at
least 8.

An int must be able to represent all possible values of unsigned char, so
INT_MAX >= UCHAR_MAX.
Why?

Richard
Mar 30 '07 #12
On 330, 9ʱ37, "Army1987" <please....@for..itwrote:
"Richard Heathfield" <r...@see.sig.invalidha scritto nel messaggionews:Pd******************************@bt. com...
What makes you think int is 4 bytes? It might be only one byte, or it
might be two bytes, or it might even be ninety-seven bytes.

It can't be one byte.
One byte is defined as the size of an unsigned char, i.e. CHAR_BIT bits.
All 2^CHAR_BIT = UCHAR_MAX + 1 possible sequences of CHAR_BIT bits mustbe
valid unsigned char representations. Also, CHAR_BIT is required to be at
least 8.

An int must be able to represent all possible values of unsigned char, so
INT_MAX >= UCHAR_MAX.
Also, it must be able to represent all negative numbers down to -INT_MAX.
So, it must be able to represent at least 2*UCHAR_MAX - 1 values. To do
that, it must have at least ceil(log2(2*UCHAR_MAX - 1)) = CHAR_BIT + 1 bits.

Since any object must occupy an integer number of bytes, an int must haveat
least 2 bytes.
It may seem very difficult and the things

Mar 30 '07 #13

"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:iL*********************@bt.com...
Army1987 said:
>>
"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:Pd******************************@bt.com...
>>What makes you think int is 4 bytes? It might be only one byte, or it
might be two bytes, or it might even be ninety-seven bytes.

It can't be one byte.

Yes, it can.
>One byte is defined as the size of an unsigned char, i.e. CHAR_BIT
bits. All 2^CHAR_BIT = UCHAR_MAX + 1 possible sequences of CHAR_BIT
bits must be valid unsigned char representations. Also, CHAR_BIT is
required to be at least 8.

All true.
>An int must be able to represent all possible values of unsigned char,

Chapter and verse, please.
What is the return type of getchar(), which can be any value from 0 to
UCHAR_MAX, or EOF, totalling 2^CHAR_BIT + 1 values?
Mar 30 '07 #14
Army1987 said:
>
"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:iL*********************@bt.com...
>Army1987 said:
<snip>
>>
>>An int must be able to represent all possible values of unsigned
char,

Chapter and verse, please.

What is the return type of getchar(), which can be any value from 0 to
UCHAR_MAX, or EOF, totalling 2^CHAR_BIT + 1 values?
The return type of getchar is of course int. Note that this int value
represents "an unsigned char converted to an int". So the conversion
rules apply. If ints are one byte in size, then if the value of the
unsigned char cannot be represented by the int, 3.2.1.2 applies:

"When an integer is demoted to a signed integer with smaller size, or an
unsigned integer is converted to its corresponding signed integer, if
the value cannot be represented the result is implementation-defined."

In C99, it's 6.3.1.3 (3), and the situation is slightly different:

"Otherwise, the new type is signed and the value cannot be represented
in it; either the result is implementation-defined or an
implementation-defined signal is raised."

In neither case (C90 or C99) is int required to be larger than one byte.
It must, of course, be at least 16 bits wide.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mar 30 '07 #15
Richard Heathfield wrote:
Army1987 said:

"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:iL*********************@bt.com...
Army1987 said:
<snip>
>
An int must be able to represent all possible values of unsigned
char,

Chapter and verse, please.
What is the return type of getchar(), which can be any value from 0 to
UCHAR_MAX, or EOF, totalling 2^CHAR_BIT + 1 values?

The return type of getchar is of course int. Note that this int value
represents "an unsigned char converted to an int".
What the standard actually says is that fgetc (and thus getc and
getchar) /obtains/ the next "character as an unsigned char converted
to an int", and /returns/ "the next character". This could be
interpreted in two different ways, supporting the claims of both of
you.

A question: does the case of UCHAR_MAX INT_MAX occur in practice on
any implementation that also provides the standard I/O facilities, or
is the possibility only used for freestanding implementations with no
standard I/O?

Mar 30 '07 #16
On Fri, 30 Mar 2007 07:46:56 GMT, "Joachim Schmitz"
<no************@hp.comwrote in comp.lang.c:
"" <wa*********@gmail.comschrieb im Newsbeitrag
news:11**********************@d57g2000hsg.googlegr oups.com...
#include <stdio.h>
Union un
union un
{ int I;
char c[2];
}
};

main()
int main(void)
{
union un x;
x.c[0]=10;
x.c[1]=1;
printf("%d",.i);
printf("%d\n",x.I);
return 0;
}
What is the output results? Please explain in detail under.
Lots of compiler errors and some warnings too, without the modifications
mentioned above. After having fixed these, on one of my machine the output
was 167838688, on another it was 1073807626.
The result is undefined behavior. The specifics of any output, or
whether there is any output at all, is meaningless in terms of the C
langauge.
Heavily depends in the implementation and machine architecture (big
endian/little endian)
Since it is not C, and the C standard places no requirements on the
program due to the undefined behavior, any further discussion is
rubbish.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Mar 31 '07 #17
On Fri, 30 Mar 2007 10:51:24 +0200, "Marcin" <bl*@bla.plwrote in
comp.lang.c:
Union un
{ int I;
char c[2];
}

After "fixing" your code to make it compiled:

- int 4 bytes
- char 1 byte, char[2] - 2 bytes

so, after union is created it is filled with trash. Then you assign a values
but only to "char" components, the other two bytes of "int" component are
still filled with "trash". So final answer is "you will get unspecified
number".
No, you will get undefined behavior. There is no number there, as far
as C is concerned.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Mar 31 '07 #18
On Fri, 30 Mar 2007 10:36:58 GMT, "Joachim Schmitz"
<no************@hp.comwrote in comp.lang.c:
"Marcin" <bl*@bla.plschrieb im Newsbeitrag
news:eu**********@atlantis.news.tpi.pl...
Union un
{ int I;
char c[2];
}
After "fixing" your code to make it compiled:

- int 4 bytes
- char 1 byte, char[2] - 2 bytes

so, after union is created it is filled with trash. Then you assign a
values
but only to "char" components, the other two bytes of "int" component are
still filled with "trash". So final answer is "you will get unspecified
number".
Ah, yes, I missed that these other bytes still may be uninitialized... (on
an implementation with sizeof(int) != 2)

but
union un x;
x.I = 0;
x.c[0]=10;
x.c[1]=1;
printf("%d",x.I);

would still give some implementation/architecture dependant output.
No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Mar 31 '07 #19
On Fri, 30 Mar 2007 15:37:10 +0200, "Army1987" <pl********@for.it>
wrote in comp.lang.c:
>
"Richard Heathfield" <rj*@see.sig.invalidha scritto nel messaggio
news:Pd******************************@bt.com...
What makes you think int is 4 bytes? It might be only one byte, or it
might be two bytes, or it might even be ninety-seven bytes.

It can't be one byte.
You are absolutely wrong. I work with an implementation regularly
where sizeof(int) is 1. CHAR_BIT is 16.

I have worked in the past with two other implementations where
sizeof(int) is 1. One had CHAR_BIT 24, the other CHAR_BIT 32.
One byte is defined as the size of an unsigned char, i.e. CHAR_BIT bits.
All 2^CHAR_BIT = UCHAR_MAX + 1 possible sequences of CHAR_BIT bits must be
valid unsigned char representations. Also, CHAR_BIT is required to be at
least 8.
The above paragraph is absolutely correct.
An int must be able to represent all possible values of unsigned char, so
INT_MAX >= UCHAR_MAX.
The above paragraph, as Richard points out, is quite wrong. Especially
in a free-standing environment, where none of the functions in the
standard library are required. There is no requirement in the
definition of the integer types that INT_MAX must be greater than or
equal to UCHAR_MAX.
Also, it must be able to represent all negative numbers down to -INT_MAX.
So, it must be able to represent at least 2*UCHAR_MAX - 1 values. To do
that, it must have at least ceil(log2(2*UCHAR_MAX - 1)) = CHAR_BIT + 1 bits.

Since any object must occupy an integer number of bytes, an int must have at
least 2 bytes.
Dead wrong, especially in free-standing environments.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Mar 31 '07 #20
Jack Klein wrote:
On Fri, 30 Mar 2007 10:36:58 GMT, "Joachim Schmitz"
<no************@hp.comwrote in comp.lang.c:
"Marcin" <bl*@bla.plschrieb im Newsbeitrag
news:eu**********@atlantis.news.tpi.pl...
>Union un
>{ int I;
>char c[2];
>}
>>
>
After "fixing" your code to make it compiled:
>
- int 4 bytes
- char 1 byte, char[2] - 2 bytes
>
so, after union is created it is filled with trash. Then you assign a
values
but only to "char" components, the other two bytes of "int" component are
still filled with "trash". So final answer is "you will get unspecified
number".
Ah, yes, I missed that these other bytes still may be uninitialized... (on
an implementation with sizeof(int) != 2)

but
union un x;
x.I = 0;
x.c[0]=10;
x.c[1]=1;
printf("%d",x.I);

would still give some implementation/architecture dependant output.

No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.
The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even if it
weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.

Mar 31 '07 #21
Harald van D?k wrote:
Jack Klein wrote:
>"Joachim Schmitz" <no************@hp.comwrote:
.... snip ...
>>>
but
union un x;
x.I = 0;
x.c[0]=10;
x.c[1]=1;
printf("%d",x.I);

would still give some implementation/architecture dependant output.

No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.

The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.
No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Mar 31 '07 #22
On Mar 31, 8:51 am, CBFalconer <cbfalco...@yahoo.comwrote:
Harald van D?k wrote:
Jack Klein wrote:
"Joachim Schmitz" <nospam.schm...@hp.comwrote:

... snip ...
>but
union un x;
x.I = 0;
x.c[0]=10;
x.c[1]=1;
printf("%d",x.I);
>would still give some implementation/architecture dependant output.
No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.
The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.

No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.
Can you provide the C&V that supports your claim of undefined behavior
given the no trap representation provision?

Robert Gamble

Mar 31 '07 #23
On Mar 31, 10:50 am, "Robert Gamble" <rgambl...@gmail.comwrote:
On Mar 31, 8:51 am, CBFalconer <cbfalco...@yahoo.comwrote:
Harald van D?k wrote:
Jack Klein wrote:
>"Joachim Schmitz" <nospam.schm...@hp.comwrote:
... snip ...
>>but
>> union un x;
>> x.I = 0;
>> x.c[0]=10;
>> x.c[1]=1;
>> printf("%d",x.I);
>>would still give some implementation/architecture dependant output.
>No, it gives you undefined behavior. If you don't understand what
>undefined behavior is, or why this program invokes it, you are not
>qualified to answer questions on this group.
The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.
No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.

Can you provide the C&V that supports your claim of undefined behavior
given the no trap representation provision?
I believe that Chuck is referring to ISO/IEC 9899:1999 (draft)
6.7.2.1.14, where it says
14 The size of a union is sufficient to contain the largest of its
members. The value of at
most one of the members can be stored in a union object at any
time. A pointer to a
union object, suitably converted, points to each of its members
(or if a member is a bit-
field, then to the unit in which it resides), and vice versa.

The key being the second sentence. The code posted above populates a
value into one member of the union, and subsequently references a
different member of the union without that subsequent member having
been populated. The "undefined behaviour" is the behaviour of the code
when the alternate member is referenced. About this behaviour, the
standard sayeth not.

Mar 31 '07 #24
On Mar 31, 11:07 am, "Lew Pitcher" <lpitc...@sympatico.cawrote:
On Mar 31, 10:50 am, "Robert Gamble" <rgambl...@gmail.comwrote:
On Mar 31, 8:51 am, CBFalconer <cbfalco...@yahoo.comwrote:
Harald van D?k wrote:
Jack Klein wrote:
"Joachim Schmitz" <nospam.schm...@hp.comwrote:
... snip ...
>but
> union un x;
> x.I = 0;
> x.c[0]=10;
> x.c[1]=1;
> printf("%d",x.I);
>would still give some implementation/architecture dependant output.
No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.
The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.
No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.
Can you provide the C&V that supports your claim of undefined behavior
given the no trap representation provision?

I believe that Chuck is referring to ISO/IEC 9899:1999 (draft)
6.7.2.1.14, where it says
14 The size of a union is sufficient to contain the largest of its
members. The value of at
most one of the members can be stored in a union object at any
time. A pointer to a
union object, suitably converted, points to each of its members
(or if a member is a bit-
field, then to the unit in which it resides), and vice versa.

The key being the second sentence. The code posted above populates a
value into one member of the union, and subsequently references a
different member of the union without that subsequent member having
been populated. The "undefined behaviour" is the behaviour of the code
when the alternate member is referenced. About this behaviour, the
standard sayeth not.
For that matter, ISO/IEC 9899:1999 (draft) J.1 says (wrt "Unspecified
Behaviour")
"The following are unspecified
...
— The value of a union member other than the last one stored into
(6.2.6.1).
"

Mar 31 '07 #25
On Mar 31, 11:07 am, "Lew Pitcher" <lpitc...@sympatico.cawrote:
On Mar 31, 10:50 am, "Robert Gamble" <rgambl...@gmail.comwrote:
On Mar 31, 8:51 am, CBFalconer <cbfalco...@yahoo.comwrote:
Harald van D?k wrote:
Jack Klein wrote:
"Joachim Schmitz" <nospam.schm...@hp.comwrote:
... snip ...
>but
> union un x;
> x.I = 0;
> x.c[0]=10;
> x.c[1]=1;
> printf("%d",x.I);
>would still give some implementation/architecture dependant output.
No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.
The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.
No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.
Can you provide the C&V that supports your claim of undefined behavior
given the no trap representation provision?

I believe that Chuck is referring to ISO/IEC 9899:1999 (draft)
6.7.2.1.14, where it says
14 The size of a union is sufficient to contain the largest of its
members. The value of at
most one of the members can be stored in a union object at any
time. A pointer to a
union object, suitably converted, points to each of its members
(or if a member is a bit-
field, then to the unit in which it resides), and vice versa.

The key being the second sentence. The code posted above populates a
value into one member of the union, and subsequently references a
different member of the union without that subsequent member having
been populated. The "undefined behaviour" is the behaviour of the code
when the alternate member is referenced. About this behaviour, the
standard sayeth not.
I think that sentence is simply pointing out the fact that since the
members overlap it is not possible to have multiple members stored at
the same time. The standard makes it clear that any object can be
accessed through unsigned char without invoking UB, this includes when
a non-char member of a union is stored and then accessed via an
unsigned char member of that union. This is always safe because
unsigned char is specified as having no trap representations.
Furthermore, DR 283 adds a footnote to 6.5.2.3#3 which reads:

"If the member used to access the contents of a union object is not
the same as the member last used to store a value in the object, the
appropriate part of the object representation of the value is
reinterpreted as an object representation in the new type as described
in 6.2.6 (a process sometimes called "type punning"). This might be a
trap representation."

This sentence would be pointless if such access was undefined
behavior. The undefined behavior comes from the fact that the
resulting representation may be a trap representation, if it is not
then there is no undefined behavior.

Robert Gamble

Mar 31 '07 #26
On Mar 31, 11:10 am, "Lew Pitcher" <lpitc...@sympatico.cawrote:
On Mar 31, 11:07 am, "Lew Pitcher" <lpitc...@sympatico.cawrote:
On Mar 31, 10:50 am, "Robert Gamble" <rgambl...@gmail.comwrote:
On Mar 31, 8:51 am, CBFalconer <cbfalco...@yahoo.comwrote:
Harald van D?k wrote:
Jack Klein wrote:
>"Joachim Schmitz" <nospam.schm...@hp.comwrote:
... snip ...
>>but
>> union un x;
>> x.I = 0;
>> x.c[0]=10;
>> x.c[1]=1;
>> printf("%d",x.I);
>>would still give some implementation/architecture dependant output.
>No, it gives you undefined behavior. If you don't understand what
>undefined behavior is, or why this program invokes it, you are not
>qualified to answer questions on this group.
The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.
No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.
Can you provide the C&V that supports your claim of undefined behavior
given the no trap representation provision?
I believe that Chuck is referring to ISO/IEC 9899:1999 (draft)
6.7.2.1.14, where it says
14 The size of a union is sufficient to contain the largest ofits
members. The value of at
most one of the members can be stored in a union object at any
time. A pointer to a
union object, suitably converted, points to each of its members
(or if a member is a bit-
field, then to the unit in which it resides), and vice versa.
The key being the second sentence. The code posted above populates a
value into one member of the union, and subsequently references a
different member of the union without that subsequent member having
been populated. The "undefined behaviour" is the behaviour of the code
when the alternate member is referenced. About this behaviour, the
standard sayeth not.

For that matter, ISO/IEC 9899:1999 (draft) J.1 says (wrt "Unspecified
Behaviour")
"The following are unspecified
...
— The value of a union member other than the last one stored into
(6.2.6.1).
"
This is a defect in the Standard, one that frustratingly causes more
confusion than any other I can think of at the moment. This is left
over from a previous Standard version, there is no supporting text for
this statement in the Standard proper. Someone should really submit a
DR for this.

Robert Gamble

Mar 31 '07 #27
Lew Pitcher wrote:
On Mar 31, 10:50 am, "Robert Gamble" <rgambl...@gmail.comwrote:
On Mar 31, 8:51 am, CBFalconer <cbfalco...@yahoo.comwrote:
Harald van D?k wrote:
Jack Klein wrote:
"Joachim Schmitz" <nospam.schm...@hp.comwrote:
... snip ...
>but
> union un x;
> x.I = 0;
> x.c[0]=10;
> x.c[1]=1;
> printf("%d",x.I);
>would still give some implementation/architecture dependant output.
No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.
The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.
No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.
Can you provide the C&V that supports your claim of undefined behavior
given the no trap representation provision?

I believe that Chuck is referring to ISO/IEC 9899:1999 (draft)
6.7.2.1.14, where it says
14 The size of a union is sufficient to contain the largest of its
members. The value of at
most one of the members can be stored in a union object at any
time. A pointer to a
union object, suitably converted, points to each of its members
(or if a member is a bit-
field, then to the unit in which it resides), and vice versa.

The key being the second sentence. The code posted above populates a
value into one member of the union, and subsequently references a
different member of the union without that subsequent member having
been populated. The "undefined behaviour" is the behaviour of the code
when the alternate member is referenced. About this behaviour, the
standard sayeth not.
The standard says that the value of at most one of the members can be
stored, but does not say that reading a different member produces
undefined behaviour. Since it doesn't, and since the code doesn't
violate the aliasing rules, reading a different member is covered by
all the usual rules.

Mar 31 '07 #28
Robert Gamble wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
>Harald van D?k wrote:
>>Jack Klein wrote:
"Joachim Schmitz" <nospam.schm...@hp.comwrote:

... snip ...
>>>>but
union un x;
x.I = 0;
x.c[0]=10;
x.c[1]=1;
printf("%d",x.I);
>>>>would still give some implementation/architecture dependant output.
>>>No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.
>>The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.

No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.

Can you provide the C&V that supports your claim of undefined
behavior given the no trap representation provision?
6.2.6.1:
... snip ...

[#7] When a value is stored in a member of an object of
union type, the bytes of the object representation that do
not correspond to that member but do correspond to other
members take unspecified values, but the value of the union
object shall not thereby become a trap representation.

... snip ...

6.5.2.3 Structure and union members

Constraints

.... snip ...

[#5] With one exception, if the value of a member of a union
object is used when the most recent store to the object was
to a different member, the behavior is
implementation-defined.70) One special guarantee is made in
order to simplify the use of unions: If a union contains
several structures that share a common initial sequence (see
below), and if the union object currently contains one of
these structures, it is permitted to inspect the common
initial part of any of them anywhere that a declaration of
the completed type of the union is visible. Two structures
share a common initial sequence if corresponding members
have compatible types (and, for bit-fields, the same widths)
for a sequence of one or more initial members.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Mar 31 '07 #29
On Mar 31, 4:40 pm, CBFalconer <cbfalco...@yahoo.comwrote:
Robert Gamble wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
Harald van D?k wrote:
Jack Klein wrote:
"Joachim Schmitz" <nospam.schm...@hp.comwrote:
... snip ...
>>>but
union un x;
x.I = 0;
x.c[0]=10;
x.c[1]=1;
printf("%d",x.I);
>>>would still give some implementation/architecture dependant output.
>>No, it gives you undefined behavior. If you don't understand what
undefined behavior is, or why this program invokes it, you are not
qualified to answer questions on this group.
>The program is guaranteed to print an unspecified value on
implementations where int has no trap representations, and even
if it weren't, the output (if any) would still be implementation/
architecture dependant. That's part of what "undefined" means.
No it isn't. The arguments are evaluated (and the undefined
behaviour occurs) _before_ the call to printf executes. It is
fairly hard to execute "call by value" without having the value
with which to call.
Can you provide the C&V that supports your claim of undefined
behavior given the no trap representation provision?

6.2.6.1:
... snip ...

[#7] When a value is stored in a member of an object of
union type, the bytes of the object representation that do
not correspond to that member but do correspond to other
members take unspecified values, but the value of the union
object shall not thereby become a trap representation.
Nothing about undefined behavior here...
>
... snip ...

6.5.2.3 Structure and union members

Constraints

... snip ...

[#5] With one exception, if the value of a member of a union
object is used when the most recent store to the object was
to a different member, the behavior is
implementation-defined.70)
[snip]

This sentence exists in a pre-C99 draft but not in the actual
Standard, there is a reason for that.

Robert Gamble

Mar 31 '07 #30
On Mar 31, 6:21 pm, "Harald van Dijk" <true...@gmail.comwrote:
union un x;
x.I = 0;
x.c[0]=10;
x.c[1]=1;
printf("%d",x.I);

The program is guaranteed to print an unspecified value on
implementations where int has no trap representations
In C89, it explicitly says that the behaviour is undefined if
you access a union member that was not the most recent one set.

In C99 this rule was relaxed and it does seem to be as you say,
with a pile of assumptions.
Apr 1 '07 #31
On Apr 1, 8:40 am, CBFalconer <cbfalco...@yahoo.comwrote:
Robert Gamble wrote:
Can you provide the C&V that supports your claim of undefined
behavior given the no trap representation provision?

6.2.6.1:
... snip ...

[#7] When a value is stored in a member of an object of
union type, the bytes of the object representation that do
not correspond to that member but do correspond to other
members take unspecified values, but the value of the union
object shall not thereby become a trap representation.
This is saying that the value of the union as a whole is
not a trap, i.e. you can pass it to functions and so on.
It doesn't say that there won't be a trap if any particular
member of the union is selected.
6.5.2.3 Structure and union members

[#5] With one exception, if the value of a member of a union
object is used when the most recent store to the object was
to a different member, the behavior is
implementation-defined.70)
This text is not in C99. I suggest that if you are to use N869
as a reference then you double check things with N1124 before
posting.
Apr 2 '07 #32
Old Wolf wrote:
On Apr 1, 8:40 am, CBFalconer <cbfalco...@yahoo.comwrote:
.... snip ...
>
> 6.5.2.3 Structure and union members

[#5] With one exception, if the value of a member of a union
object is used when the most recent store to the object was
to a different member, the behavior is
implementation-defined.70)

This text is not in C99. I suggest that if you are to use N869
as a reference then you double check things with N1124 before
posting.
Made a note. Hopefully I will get around to checking this and
possibly editing my copy of N869 later.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Apr 2 '07 #33

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

36
by: Bhalchandra Thatte | last post by:
I am allocating a block of memory using malloc. I want to use it to store a "header" structure followed by structs in my application. How to calculate the alignment without making any assumption...
73
by: Sean Dolan | last post by:
typedef struct ntt { int type; union { int i; char* s; }; }nt; nt n; n.i = 0;
47
by: sunglo | last post by:
Some time a go, in a discussion here in comp.lang.c, I learnt that it's better not to use a (sometype **) where a (void **) is expected (using a cast). Part of the discussion boiled down to the...
16
by: tedu | last post by:
does anyone know of a platform/compiler which will place union elements to not overlap? as in union u { int a; long b; size_t c; }; in my limited experience, writing to any of (a, b, or c)...
28
by: WaterWalk | last post by:
Hi, I'm haunted by 2 questions about struct copy. Though I searched the net, but still in confusion. 1. Does struct assignment copies every member including array members? For example, struct...
7
by: JDT | last post by:
NM_UPDOWN With UDN_DELTAPOS notification handler, MS passes a pointer to NMHDR which yo can cast to NM_UPDOWN*. With NMHDR (shown below) , you can use "iDelta" to know the amount it spins while...
5
by: wugon.net | last post by:
question: db2 LUW V8 UNION ALL with table function month() have bad query performance Env: db2 LUW V8 + FP14 Problem : We have history data from 2005/01/01 ~ 2007/05/xx in single big...
9
by: dspfun | last post by:
Hi! I have stumbled on the following C question and I am wondering wether the answer is implementation specific or if the answer is always valid, especially question b). BRs! ...
4
by: hugo.arregui | last post by:
Hi! I have two struts like that: struct { int num; int num2; struct b arrayOfB; } a;
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, youll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shllpp 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.