Ok, we've had two long and haphazard threads about unions recently,
and I still don't feel any closer to certainty about what is permitted
and what isn't. The other thread topics were "Real Life Unions"
and "union {unsigned char u[10]; ...} ".
Here's a concrete example:
#include <stdio.h>
int main(void)
{
union { int s; unsigned int us; } u;
u.us = 50;
printf("%d\n", u.s);
return 0;
}
Is this program well-defined (printing 50), implementation-defined, or
UB ?
Note that the aliasing rules in C99 6.5 are not violated here -- it is
not forbidden under that section to access an object of some type T
with an lvalue expression whose type is the signed or unsigned
version of T.
In other words, is there anything other than the aliasing rules that
restrict 'free' use of unions?
Mar 14 '07
26  1926  mu*****@gmail.c om wrote:
/* make sure no trap representation involved */
How do you propose to do that ?
--
pa at panix dot com
On Mar 18, 6:53 pm, munt...@gmail.c om wrote:
On Mar 18, 5:36 pm, "Old Wolf" <oldw...@inspir e.net.nzwrote:
On Mar 17, 3:13 am, Yevgen Muntyan <muntyan.remove t...@tamu.edu>
wrote:
It was unsigned int. I specifically chose it and assumed no padding bits
in int to avoid problems with representation.
#if 1
#define LONGSIZE 4
#else
#define LONGSIZE 8
#endif
Look, none of this matters. The C Standard explicitly says that
it is undefined behaviour to read the bit pattern of a double as
if it were an unsigned int (and vice versa) -- end of story. It
doesn't say "sometimes undefined" or "undefined if size of long
is not 4 blah blah blah".
Where does it say that? Is it aliasing rules or something else?
Because I was suggested here it doesn't matter whether we do
memcpy(&intval, &doubleval, sizeof intval);
or
memcpy(chararra y, &doubleval, sizeof intval);
memcpy(&intval, chararray, sizeof intval);
and clearly aliasing rules do not apply to the latter. If it's indeed
aliasing rules, then so be it, it'd be a magic and it'd be fine. In
two posts I was told about trap values, which I take as a possible
explanation of why standard would opt to say something is undefined
(i.e. the reason, the rationale), this is fine. But what exactly place
in the standard says that
unsigned long longval;
unsigned int intval;
/* make sure no trap representation involved */
...
memcpy(&intval, &longval, sizeof intval);
First off, as far as I can tell, none of your examples violate the
aliasing rules. Second, if the change to the bit-representation of an
object does not result in a trap representation, using the value does
not result in undefined behavior. Determining that the result is not
a trap representation is of course not easy to do in a portable way.
Robert Gamble
On Mar 18, 7:33 pm, "Robert Gamble" <rgambl...@gmai l.comwrote:
On Mar 18, 6:53 pm, munt...@gmail.c om wrote:
On Mar 18, 5:36 pm, "Old Wolf" <oldw...@inspir e.net.nzwrote:
On Mar 17, 3:13 am, Yevgen Muntyan <muntyan.remove t...@tamu.edu>
wrote:
It was unsigned int. I specifically chose it and assumed no padding bits
in int to avoid problems with representation.
#if 1
#define LONGSIZE 4
#else
#define LONGSIZE 8
#endif
Look, none of this matters. The C Standard explicitly says that
it is undefined behaviour to read the bit pattern of a double as
if it were an unsigned int (and vice versa) -- end of story. It
doesn't say "sometimes undefined" or "undefined if size of long
is not 4 blah blah blah".
Where does it say that? Is it aliasing rules or something else?
Because I was suggested here it doesn't matter whether we do
memcpy(&intval, &doubleval, sizeof intval);
or
memcpy(chararra y, &doubleval, sizeof intval);
memcpy(&intval, chararray, sizeof intval);
and clearly aliasing rules do not apply to the latter. If it's indeed
aliasing rules, then so be it, it'd be a magic and it'd be fine. In
two posts I was told about trap values, which I take as a possible
explanation of why standard would opt to say something is undefined
(i.e. the reason, the rationale), this is fine. But what exactly place
in the standard says that
unsigned long longval;
unsigned int intval;
/* make sure no trap representation involved */
...
memcpy(&intval, &longval, sizeof intval);
First off, as far as I can tell, none of your examples violate the
aliasing rules. Second, if the change to the bit-representation of an
object does not result in a trap representation, using the value does
not result in undefined behavior. Determining that the result is not
a trap representation is of course not easy to do in a portable way.
I posted code which *ensures* there are no problems with
representation. The memcpy() call isn't going to be executed on all
possible implementations , but it's going to be called on some (e.g.
your or mine), and if it's called then there are no problems with
representation [1].
So you are saying it's fine to copy bits from double to an int *given*
no representation problems happen. If I messed up in the last
sentence, then this one: my example with kind_of_log2 is strictly-
conforming (after you fix obvious mistake in kind_of_log2 and perhaps
other mistakes I didn't notice).
The post I replied to said "it's UB because standard explicitly says
so". I guess I am not the only one confused by this stuff.
Yevgen
On Mar 15, 10:20 pm, Jack Klein <jackkl...@spam cop.netwrote:
On Thu, 15 Mar 2007 05:55:15 GMT, Yevgen Muntyan
<muntyan.remove t...@tamu.eduwr ote in comp.lang.c:
Jack Klein wrote:
On 14 Mar 2007 15:10:44 -0700, "Old Wolf" <oldw...@inspir e.net.nz>
wrote in comp.lang.c:
>Ok, we've had two long and haphazard threads about unions recently,
>and I still don't feel any closer to certainty about what is permitted
>and what isn't. The other thread topics were "Real Life Unions"
>and "union {unsigned char u[10]; ...} ".
Most of the rambling was caused by the original OP, I think, rather
than the material. I am not criticizing, just observing.
[snip]
There is no difference in aliasing in a union than there is via
pointer casting.
Sorry if it's something obvious or stupid, but please consider this
(no pointers involved).
You are mistaken, of course there are pointers involved. Just not
pointer objects.
Suppose double is eight bytes big, int is four bytes, there are
no padding bits in int.
/* (1) get bits from a double and see what happens */
double a = 3.45; unsigned int b;
memcpy(&b, &a, sizeof b);
There are two pointers used in the function call statement. The &
operator generates two addresses, which are passed to memcpy() as
pointers to void.
printf("%u", b);
The behavior is undefined.
/* (2) do same thing using a union */
union U {double a; unsigned int b;} u;
u.a = 3.14;
printf("%u", u.b);
The behavior is undefined.
/* (3) initialize union with memcpy and access its member */
double d;
union U {double a; unsigned int b;} u;
d = 3.14;
memcpy(&u, &d, sizeof d);
printf("%u", u.b);
The behavior is undefined.
Which of three are valid? I think (1) is; (3) maybe; (2) maybe, if
(3) valid and aliasing rules don't work here. If aliasing rules
do apply to (2), then how is first assignment in (2) different
from memcpy() in (3)?
None of the three are valid. The standard does not give you
permission to access an lvalue of type unsigned int after writing some
or all of the bits of a double to it.
C&V please.
Robert Gamble
On Mar 19, 10:53 am, munt...@gmail.c om wrote:
On Mar 18, 5:36 pm, "Old Wolf" <oldw...@inspir e.net.nzwrote:
Look, none of this matters. The C Standard explicitly says that
it is undefined behaviour to read the bit pattern of a double as
if it were an unsigned int (and vice versa) -- end of story. It
doesn't say "sometimes undefined" or "undefined if size of long
is not 4 blah blah blah".
Where does it say that?
C99 6.5#6 and 6.5#7 .
Is it aliasing rules
Yes
Because I was suggested here it doesn't matter whether we do
memcpy(&intval, &doubleval, sizeof intval);
or
memcpy(chararra y, &doubleval, sizeof intval);
memcpy(&intval, chararray, sizeof intval);
Those two both have the same effect, if chararray is big enough.
and clearly aliasing rules do not apply to the latter.
Actually they do. (See below)
But what exactly place in the standard says that
unsigned long longval;
unsigned int intval;
/* make sure no trap representation involved */
...
memcpy(&intval, &longval, sizeof intval);
is undefined?
It isn't undefined. The behaviour is only undefined if you
subsequently
evaluate the value of 'intval'. The reason it is undefined at that
point
is because of the aliasing rules: you are using an 'unsigned int'
lvalue
to access a bit pattern that is (part of) the bit pattern of a
different
type (namely, unsigned long).
'trap representation' also does not come into it unless you evaluate
intval. Memory is just memory, you can write whatever crap you want
into it. Problems only arise when you try and treat said crap as if
you are expecting a valid value.
On Mar 18, 11:07 pm, "Old Wolf" <oldw...@inspir e.net.nzwrote:
On Mar 19, 10:53 am, munt...@gmail.c om wrote:
On Mar 18, 5:36 pm, "Old Wolf" <oldw...@inspir e.net.nzwrote:
Look, none of this matters. The C Standard explicitly says that
it is undefined behaviour to read the bit pattern of a double as
if it were an unsigned int (and vice versa) -- end of story. It
doesn't say "sometimes undefined" or "undefined if size of long
is not 4 blah blah blah".
Where does it say that?
C99 6.5#6 and 6.5#7 .
Is it aliasing rules
Yes
Because I was suggested here it doesn't matter whether we do
memcpy(&intval, &doubleval, sizeof intval);
or
memcpy(chararra y, &doubleval, sizeof intval);
memcpy(&intval, chararray, sizeof intval);
Those two both have the same effect, if chararray is big enough.
and clearly aliasing rules do not apply to the latter.
Actually they do. (See below)
But what exactly place in the standard says that
unsigned long longval;
unsigned int intval;
/* make sure no trap representation involved */
...
memcpy(&intval, &longval, sizeof intval);
is undefined?
It isn't undefined. The behaviour is only undefined if you
subsequently
evaluate the value of 'intval'. The reason it is undefined at that
point
is because of the aliasing rules: you are using an 'unsigned int'
lvalue
to access a bit pattern that is (part of) the bit pattern of a
different
type (namely, unsigned long).
6.5p6 starts out:
"An object shall have its stored value accessed only by an lvalue
expression that has one of
the following types:"
"access" is defined as "to read or modify the value of an object".
According to your logic, the following would invoke undefined
behavior:
union {int i; float f;} u;
u.f = 1.2;
u.i = 10;
That seems pretty silly.
Robert Gamble
On Mar 18, 10:07 pm, "Old Wolf" <oldw...@inspir e.net.nzwrote:
On Mar 19, 10:53 am, munt...@gmail.c om wrote:
On Mar 18, 5:36 pm, "Old Wolf" <oldw...@inspir e.net.nzwrote:
Look, none of this matters. The C Standard explicitly says that
it is undefined behaviour to read the bit pattern of a double as
if it were an unsigned int (and vice versa) -- end of story. It
doesn't say "sometimes undefined" or "undefined if size of long
is not 4 blah blah blah".
Where does it say that?
C99 6.5#6 and 6.5#7 .
6.5p6 only says that after 'unsigned b;' effective type of b is
unsigned.
It's not obviouos that 6.5p7 talks about any access to the value at
any time
(access as in "look at what is *or was* inside the object"). Say, we
can take a
double, copy it to a character array, print bits to the screen, ask
user to enter
them back, and then set individual bits in an unsigned value [1]. We
*can* set any
bits we like in an unsigned, it's just arithmetic operations.
If character array here is important and aliasing rules stop working
after copying
into a character array, then it contradicts to what you said below. If
aliasing
rules stop after we ask user to enter value, then it's *magic* (we
could write
sequence of 0 and 1 characters to a file for that matter).
>
Is it aliasing rules
Yes
Because I was suggested here it doesn't matter whether we do
memcpy(&intval, &doubleval, sizeof intval);
or
memcpy(chararra y, &doubleval, sizeof intval);
memcpy(&intval, chararray, sizeof intval);
Those two both have the same effect, if chararray is big enough.
Yevgen
[1] This is not necessarily some simple arithmetic operation like
uint_val = uchar_array[0] + (1u<<CHAR_BIT)* uchar_array[0] + ...
of course; but we can get the mapping from unsigned value bits to bits
in unsigned char array by simply looking at the result of
unsigned foo = 1u << n;
memcpy(&char_ar ray, &foo, sizeof foo);
It assumes absence of padding bits (which we *may* assume). This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Sue |
last post by:
Anyone have any ideas on why the code below will show up
in a browser's sourcecode as an empty table, and is not
visible?
aspx:
<headertemplate>
<asp:Table ID="MyTable" runat="server" />
</headertemplate>
|
by: David |
last post by:
Some developers in my group are using UNIONS to define their data
types in a C++ program for an embedded system. Are there any pro and
cons in doing this when you can define a CLASS to do the same thing?
I guess there might be some additional overhead with CLASSES, but is
that really an issue with today's computers?
|
by: Neil Zanella |
last post by:
Hello,
I would like to know whether the following C fragment is legal in
standard C and behaves as intended under conforming implementations...
union foo {
char c;
double d;
};
|
by: Tim Cambrant |
last post by:
Hi. I was reading up a bit on the features of C I seldom use, and I came
across unions. I understand the concept, and that all the contained
variables etc. share the same memory. Thus, when a new value is declared to
a variable in the union, the existing value is overwritten even though the
new value is declared to a different variable than that of the first value.
Now I'm just wondering what the use of this is. I'm sure there are lots,...
|
by: rohit |
last post by:
Hi,
In my couple of years of experience, I have never found a single
instance where I needed to use unions and bitfields(though I have used
structures).I was just imagining where would these find
relevance.Though both of these(bitfields and unions) are used where
space is a constraint(so I can assume always in embedded systems,where
memory is particularly less)and we want to save space/memory.
As far as I have read, there is no...
| | |
by: uralmutlu |
last post by:
Hi,
I was wandering if I can have classes in unions?
I basically have source code in a format very similar to:
union example {
ClassA variable1;
ClassB variable2;
};
|
by: bluejack |
last post by:
A recent post asking for help with unions reminded me of this
component of the C language that I have only used a couple of times,
and those almost entirely out of personal whim -- Unions for the sake
of Unions simply because I wanted to see one in action.
Granted: it makes it possible to save a few bytes of storage when you
have something that can be a chicken or a rooster, but not both, and
you're always going to know which it is.
...
|
by: pereges |
last post by:
Hello, can some one please guide me a little into using unions. I read
about unions in K & R but I am finding it difficult to apply to my
problem at hand. I want to save up some space by using unions . My
questions are :
1. Is it dangerous to use unions ? Is it worth the trouble if I want
to save memory ? Are they error prone ?
2. I read that it is not possible to access more than 1 member at any
instant from a union. What does this...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
