Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Aliasing/Torek's strtod() experience

Reply
Thread Tools

Aliasing/Torek's strtod() experience

 
 
Adam Warner
Guest
Posts: n/a
 
      06-29-2005
Hi all,

Message ID <(E-Mail Removed)> is one of many informative
articles by Chris Torek about C. The particular message discusses aliasing
and concludes with this paragraph:

Under these strict type-aliasing rules, casting from (e.g.) "int *" to
"short *" is not only quite suspicious, it is also likely to cause
puzzling behavior, at least if you expect your "short *" to access or
modify your "int". Even the time-honored, albeit dubious, practise of
breaking a 64-bit IEEE "double" into two 32-bit integers (int or long
depending on the CPU involved) via a union need not work, and sometimes
does not. (We had a problem with strtod() not working right because of
code just like this. It worked in older gcc compilers, and eventually
failed when gcc began doing type-specific alias analysis and
optimizations.)

The code I've written below breaks an 8 byte double into two 4 byte
unsigned integers via a union. How should this code be modified so it
conforms to C's aliasing rules?

#include <assert.h>
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>

union u {
double f64;
uint32_t u32[2];
};

int main() {
assert(sizeof(double)==;
double val=strtod("1.23", NULL);
printf("%i %i\n", ((union u) val).u32[0], ((union u) val).u32[1]);
return 0;
}

Many thanks,
Adam
 
Reply With Quote
 
 
 
 
Grumble
Guest
Posts: n/a
 
      06-29-2005
Adam Warner wrote:

> Message ID <(E-Mail Removed)> is one of many informative
> articles by Chris Torek about C. The particular message discusses aliasing
> and concludes with this paragraph:
>
> Under these strict type-aliasing rules, casting from (e.g.) "int *" to
> "short *" is not only quite suspicious, it is also likely to cause
> puzzling behavior, at least if you expect your "short *" to access or
> modify your "int". Even the time-honored, albeit dubious, practise of
> breaking a 64-bit IEEE "double" into two 32-bit integers (int or long
> depending on the CPU involved) via a union need not work, and sometimes
> does not. (We had a problem with strtod() not working right because of
> code just like this. It worked in older gcc compilers, and eventually
> failed when gcc began doing type-specific alias analysis and
> optimizations.)
>
> The code I've written below breaks an 8 byte double into two 4 byte
> unsigned integers via a union. How should this code be modified so it
> conforms to C's aliasing rules?
>
> #include <assert.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> union u {
> double f64;
> uint32_t u32[2];
> };
>
> int main() {
> assert(sizeof(double)==;
> double val=strtod("1.23", NULL);
> printf("%i %i\n", ((union u) val).u32[0], ((union u) val).u32[1]);
> return 0;
> }


I am not sure it is safe to cast 'double' to 'union u'.

In C89, writing to member f64, then reading from member u32 has
implementation-defined behavior - 6.5.2.3 #5.
 
Reply With Quote
 
 
 
 
Adam Warner
Guest
Posts: n/a
 
      06-29-2005
On Wed, 29 Jun 2005 10:22:13 +0200, Grumble wrote:

>> The code I've written below breaks an 8 byte double into two 4 byte
>> unsigned integers via a union. How should this code be modified so it
>> conforms to C's aliasing rules?
>>
>> #include <assert.h>
>> #include <stdint.h>
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> union u {
>> double f64;
>> uint32_t u32[2];
>> };
>>
>> int main() {
>> assert(sizeof(double)==;
>> double val=strtod("1.23", NULL);
>> printf("%i %i\n", ((union u) val).u32[0], ((union u) val).u32[1]);
>> return 0;
>> }

>
> I am not sure it is safe to cast 'double' to 'union u'.
>
> In C89, writing to member f64, then reading from member u32 has
> implementation-defined behavior - 6.5.2.3 #5.


I suspect aliasing rules are better specified in C99 (6.5 #7):

An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
-- a type compatible with the effective type of the object,
-- a qualified version of a type compatible with the effective type of
the object,
-- a type that is the signed or unsigned type corresponding to the
effective type of the object,
-- a type that is the signed or unsigned type corresponding to a
qualified version of the effective type of the object,
-- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union), or
-- a character type.

Doesn't the second to last point mean that writing to member f64 then
reading from member u32 is well specified in C99?

If so is this approach conforming:

double val=strtod("1.23", NULL);
union u tmp;
tmp.f64=val;
printf("%i %i\n", tmp.u32[0], tmp.u32[1]);

(This eliminates the dubious casts, which is aways a good sign!)

Regards,
Adam
 
Reply With Quote
 
Lawrence Kirby
Guest
Posts: n/a
 
      06-29-2005
On Wed, 29 Jun 2005 13:29:59 +1200, Adam Warner wrote:

> Hi all,
>
> Message ID <(E-Mail Removed)> is one of many informative
> articles by Chris Torek about C. The particular message discusses aliasing
> and concludes with this paragraph:
>
> Under these strict type-aliasing rules, casting from (e.g.) "int *" to
> "short *" is not only quite suspicious, it is also likely to cause
> puzzling behavior, at least if you expect your "short *" to access or
> modify your "int". Even the time-honored, albeit dubious, practise of
> breaking a 64-bit IEEE "double" into two 32-bit integers (int or long
> depending on the CPU involved) via a union need not work, and sometimes
> does not. (We had a problem with strtod() not working right because of
> code just like this. It worked in older gcc compilers, and eventually
> failed when gcc began doing type-specific alias analysis and
> optimizations.)
>
> The code I've written below breaks an 8 byte double into two 4 byte
> unsigned integers via a union. How should this code be modified so it
> conforms to C's aliasing rules?


What is it you want to achieve by doing this? It is inherently
non-portable even without the aliasing rules. The simple answer would be
don't do it at all.

> #include <assert.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> union u {
> double f64;
> uint32_t u32[2];
> };
>
> int main() {
> assert(sizeof(double)==;
> double val=strtod("1.23", NULL);
> printf("%i %i\n", ((union u) val).u32[0], ((union u) val).u32[1]);
> return 0;
> }


One way to get around the aliasing rules is to memcpy() from a double
object to a separate array of uint32_t. Or maybe you don't need to use
uint32_t, you can access any object as a array of unsigned char which
allows you to access the representation of that object. So

double f64;
unsigned char *p = (unsigned char *)&f64;

and you can access p[0] to p[(sizeof f64)-1]. That's essentially that the
memcpy() is doing.

Lawrence

 
Reply With Quote
 
Adam Warner
Guest
Posts: n/a
 
      06-29-2005
On Wed, 29 Jun 2005 12:32:56 +0100, Lawrence Kirby wrote:
> On Wed, 29 Jun 2005 13:29:59 +1200, Adam Warner wrote:
>
>> Hi all,
>>
>> Message ID <(E-Mail Removed)> is one of many informative
>> articles by Chris Torek about C. The particular message discusses aliasing
>> and concludes with this paragraph:
>>
>> Under these strict type-aliasing rules, casting from (e.g.) "int *" to
>> "short *" is not only quite suspicious, it is also likely to cause
>> puzzling behavior, at least if you expect your "short *" to access or
>> modify your "int". Even the time-honored, albeit dubious, practise of
>> breaking a 64-bit IEEE "double" into two 32-bit integers (int or long
>> depending on the CPU involved) via a union need not work, and sometimes
>> does not. (We had a problem with strtod() not working right because of
>> code just like this. It worked in older gcc compilers, and eventually
>> failed when gcc began doing type-specific alias analysis and
>> optimizations.)
>>
>> The code I've written below breaks an 8 byte double into two 4 byte
>> unsigned integers via a union. How should this code be modified so it
>> conforms to C's aliasing rules?

>
> What is it you want to achieve by doing this?


Knowledge of how the issue described above might have been worked around.

>> #include <assert.h>
>> #include <stdint.h>
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> union u {
>> double f64;
>> uint32_t u32[2];
>> };
>>
>> int main() {
>> assert(sizeof(double)==;
>> double val=strtod("1.23", NULL);
>> printf("%i %i\n", ((union u) val).u32[0], ((union u) val).u32[1]);
>> return 0;
>> }

>
> One way to get around the aliasing rules is to memcpy() from a double
> object to a separate array of uint32_t. Or maybe you don't need to use
> uint32_t, you can access any object as a array of unsigned char which
> allows you to access the representation of that object. So
>
> double f64;
> unsigned char *p = (unsigned char *)&f64;
>
> and you can access p[0] to p[(sizeof f64)-1]. That's essentially that the
> memcpy() is doing.


That's two ways I hadn't thought of, thanks.

Can you please confirm that my followup suggestion to assign the double to
the union and then access it as integers is also a conforming (to C99)
approach:

double val=strtod("1.23", NULL);
union u tmp;
tmp.f64=val;
printf("%i %i\n", tmp.u32[0], tmp.u32[1]);

Regards,
Adam
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      06-29-2005
Adam Warner wrote:
> On Wed, 29 Jun 2005 10:22:13 +0200, Grumble wrote:
>
>
>>>The code I've written below breaks an 8 byte double into two 4 byte
>>>unsigned integers via a union. How should this code be modified so it
>>>conforms to C's aliasing rules?
>>>
>>>#include <assert.h>
>>>#include <stdint.h>
>>>#include <stdlib.h>
>>>#include <stdio.h>
>>>
>>>union u {
>>> double f64;
>>> uint32_t u32[2];
>>>};
>>>
>>>int main() {
>>> assert(sizeof(double)==;
>>> double val=strtod("1.23", NULL);
>>> printf("%i %i\n", ((union u) val).u32[0], ((union u) val).u32[1]);
>>> return 0;
>>>}

>>
>>I am not sure it is safe to cast 'double' to 'union u'.
>>
>>In C89, writing to member f64, then reading from member u32 has
>>implementation-defined behavior - 6.5.2.3 #5.

>
>
> I suspect aliasing rules are better specified in C99 (6.5 #7):
>
> An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types:
> -- a type compatible with the effective type of the object,
> -- a qualified version of a type compatible with the effective type of
> the object,
> -- a type that is the signed or unsigned type corresponding to the
> effective type of the object,
> -- a type that is the signed or unsigned type corresponding to a
> qualified version of the effective type of the object,
> -- an aggregate or union type that includes one of the aforementioned
> types among its members (including, recursively, a member of a
> subaggregate or contained union), or
> -- a character type.
>
> Doesn't the second to last point mean that writing to member f64 then
> reading from member u32 is well specified in C99?
>
> If so is this approach conforming:
>
> double val=strtod("1.23", NULL);
> union u tmp;
> tmp.f64=val;
> printf("%i %i\n", tmp.u32[0], tmp.u32[1]);
>
> (This eliminates the dubious casts, which is aways a good sign!)


I do not have a standard handy right now, so I cannot prove the
following by chapter and verse; AFAIR there is nothing explicitly
stating that you can only access a union member you previously stored
to but for something in the infamous Annex J.
For members of the same size the only convincing argument I know
(and saw once upon a time in c.l.c) is that an implementation could
store different members in different places, e.g. the compiler stores
a 64bit floating point variable in a register and "leaves" the yet
unused array where it is in memory. As there is nothing explicitly
forbidding this, you could see a nasty surprise.
One can come up with volatile, though.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Walter Roberson
Guest
Posts: n/a
 
      06-29-2005
In article <(E-Mail Removed)> ,
Adam Warner <(E-Mail Removed)> wrote:
>I suspect aliasing rules are better specified in C99 (6.5 #7):


> An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types:


> -- an aggregate or union type that includes one of the aforementioned
> types among its members (including, recursively, a member of a
> subaggregate or contained union), or


>Doesn't the second to last point mean that writing to member f64 then
>reading from member u32 is well specified in C99?


I don't have the C99 standard available, but such a thing would be
a notable departure from C89.

In C89, it is clear that the only time you can read a union with
"a different type" than you last stored into it, is in the case
where the two union elements have a common prefix, so at the lowest
level you are reading the same type, even if the aggregate type name
is different.

One cannot, though, expect this to work if the common prefix is not
exactly compatable at each element, as there could be differences in
padding. For example, one might know that sizeof(float) == sizeof(int)
but if the prefix in one version was a float, and the prefix in the
other version was an int, then the behaviour of reading the next value
afterwards is not defined, since the padding for float could be
different than the padding for int.

--
'ignorandus (Latin): "deserving not to be known"'
-- Journal of Self-Referentialism
 
Reply With Quote
 
Adam Warner
Guest
Posts: n/a
 
      06-29-2005
On Wed, 29 Jun 2005 22:39:39 +0200, Michael Mair wrote:

>>>I am not sure it is safe to cast 'double' to 'union u'.
>>>
>>>In C89, writing to member f64, then reading from member u32 has
>>>implementation-defined behavior - 6.5.2.3 #5.

>>
>> I suspect aliasing rules are better specified in C99 (6.5 #7):
>>
>> An object shall have its stored value accessed only by an lvalue
>> expression that has one of the following types:
>> -- a type compatible with the effective type of the object,
>> -- a qualified version of a type compatible with the effective type of
>> the object,
>> -- a type that is the signed or unsigned type corresponding to the
>> effective type of the object,
>> -- a type that is the signed or unsigned type corresponding to a
>> qualified version of the effective type of the object,
>> -- an aggregate or union type that includes one of the aforementioned
>> types among its members (including, recursively, a member of a
>> subaggregate or contained union), or
>> -- a character type.
>>
>> Doesn't the second to last point mean that writing to member f64 then
>> reading from member u32 is well specified in C99?
>>
>> If so is this approach conforming:
>>
>> double val=strtod("1.23", NULL);
>> union u tmp;
>> tmp.f64=val;
>> printf("%i %i\n", tmp.u32[0], tmp.u32[1]);
>>
>> (This eliminates the dubious casts, which is always a good sign!)

>
> I do not have a standard handy right now, so I cannot prove the
> following by chapter and verse; AFAIR there is nothing explicitly
> stating that you can only access a union member you previously stored
> to but for something in the infamous Annex J.


"The following are unspecified: ... The value of a union member other
than the last one stored into (6.2.6.1)."

There appear to be two instances where this is unspecified in 6.2.6.1:

When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object representation
that correspond to any padding bytes take unspecified values.42) The
values of padding bytes shall not affect whether the value of such an
object is a trap representation. Those bits of a structure or union
object that are in the same byte as a bit-field member, but are not
part of that member, shall similarly not affect whether the value of
such an object is a trap representation.

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.

Unspecified instance 1 is not applicable when there are no corresponding
padding bytes to take unspecified values. I mapped two 4 byte integers
onto an 8 byte double (I checked the double was 8 bytes with an assertion).
As all members of a union are aligned to the same starting address the two
member objects overlap perfectly.

Unspecified instance 2 is also not applicable because the bytes of both
object representations overlap perfectly.

> For members of the same size the only convincing argument I know
> (and saw once upon a time in c.l.c) is that an implementation could
> store different members in different places, e.g. the compiler stores
> a 64bit floating point variable in a register and "leaves" the yet
> unused array where it is in memory. As there is nothing explicitly
> forbidding this, you could see a nasty surprise.
> One can come up with volatile, though.


"A union type describes an overlapping nonempty set of member objects
...." If member objects behave as if they are stored in different places
then they don't semantically overlap. I don't think this argument you
read is at all convincing. Regardless of how member objects within a union
are implemented they should behave _as if they overlap_.

Regards,
Adam
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      07-13-2005
Michael Mair <(E-Mail Removed)> writes:

> Adam Warner wrote:
>
> [... storing into one member of a union, accessing another ...]
>
> I do not have a standard handy right now, so I cannot prove the
> following by chapter and verse; AFAIR there is nothing explicitly
> stating that you can only access a union member you previously stored
> to but for something in the infamous Annex J.
> For members of the same size the only convincing argument I know
> (and saw once upon a time in c.l.c) is that an implementation could
> store different members in different places, e.g. the compiler stores
> a 64bit floating point variable in a register and "leaves" the yet
> unused array where it is in memory. As there is nothing explicitly
> forbidding this, you could see a nasty surprise.
> One can come up with volatile, though.


My understanding is that the storing one member of a union in
different memory than another member was the result of unclear
language in the standard, and that the unclear language is
expected to be addressed through a TC. See:

http://www.open-std.org/jtc1/sc22/wg...ocs/dr_283.htm
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      07-13-2005
Tim Rentsch wrote:
> Michael Mair <(E-Mail Removed)> writes:
>
>
>>Adam Warner wrote:
>>
>>[... storing into one member of a union, accessing another ...]
>>
>>I do not have a standard handy right now, so I cannot prove the
>>following by chapter and verse; AFAIR there is nothing explicitly
>>stating that you can only access a union member you previously stored
>>to but for something in the infamous Annex J.
>>For members of the same size the only convincing argument I know
>>(and saw once upon a time in c.l.c) is that an implementation could
>>store different members in different places, e.g. the compiler stores
>>a 64bit floating point variable in a register and "leaves" the yet
>>unused array where it is in memory. As there is nothing explicitly
>>forbidding this, you could see a nasty surprise.
>>One can come up with volatile, though.

>
>
> My understanding is that the storing one member of a union in
> different memory than another member was the result of unclear
> language in the standard, and that the unclear language is
> expected to be addressed through a TC. See:
>
> http://www.open-std.org/jtc1/sc22/wg...ocs/dr_283.htm


Thank you very much!
So, this really is not outlawed but only to be used with care
(and, usually, in an implementation defined way).


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
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
Experience Beta 2 Kit Elvis ASP .Net 1 07-27-2005 11:39 AM
Samsung Experience (6.17.05) Event Coverage at XYZ Computing Silverstrand Front Page News 3 06-26-2005 07:10 AM
OPINIONS/EXPERIENCE PLEASE: Wireless Network Adapters and Base Stations of different brands Jimmy Dean Wireless Networking 2 02-22-2005 02:42 PM
Storable - Anyone with experience with this perl mod? Harsha Perl 1 09-11-2004 07:39 PM
Is there a person who I experience absurd event that experience? PS2 gamer Cisco 4 06-01-2004 07:52 PM



Advertisments