Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: [union] Pointers to inherited structs are valid ? |
| Date | 2013-01-03 20:55 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <kc5cpu$6af$1@dont-email.me> (permalink) |
| References | <afef3988-7b31-4d55-bf9a-29ab7a835403@x20g2000vbf.googlegroups.com> <kc04nr$38p$1@dont-email.me> <kfnpq1nctkv.fsf@x-alumni2.alumni.caltech.edu> <kc2kvg$in7$1@dont-email.me> <kfnd2xldetc.fsf@x-alumni2.alumni.caltech.edu> |
On 1/3/2013 18:31, Tim Rentsch wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>
>> On 1/2/2013 13:45, Tim Rentsch wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>> But the implementation's actual pointer representation could be
>>>> complicated and so there's still no guarantee. If you can dream up a
>>>> pointer representation, then you can dream up a counter-example to
>>>> your code's portability.
>>>
>>> The stipulation that all pointers to structs have the same
>>> representation and alignment requirements means that the
>>> type-punning union member access has to work. That's what
>>> having the same represention means -- that the same object
>>> representation (ie, the same bytes) will have the same value.
>>> Any choice of representations for the two cases that doesn't
>>> produce identical results here means the two representations
>>> are not the same, ie, the implementation is not conforming
>>> (under C99/C11 rules).
>>>
>>
>> Here are three examples that I would consider to be counter-examples:
>>
>> 1. A 'struct any *' pointer representation that is a simple index.
>>
>> This could provide a level of indirection into a table. The table
>> element could have type and bounds information, along with some other
>> form of address for the pointee. When the representation (a simple
>> index) is loaded into a 'struct bar *' instead of into a 'struct foo
>> *', a trap could be generated.
>>
>> 2. A 'struct any *' pointer representation that encodes bounds
>> information. While the original post "has this covered" because the
>> bounds of the the original pointee encompass the bounds of the members
>> and sub-members, it's not safe in the general case. When the
>> representation is loaded into a 'struct bigger *' instead of a 'struct
>> smaller *', the bounds mismatch could generate a trap.
>>
>> 3. A 'struct any *' pointer representation that encodes type
>> information. Maybe for the sole reason of generating a trap when the
>> representation is loaded into an incompatible pointer type of object.
>
> These ideas aren't consistent with how the Standard uses the
> notion of having the same representation in other instances. For
> example, an object of type (int) has the same representation and
> alignment requirements as an object of type (const int). Yet it's
> ridiculous to think that loading an (int) object through a pointer
> of type (const int *) might cause a trap when accessing the object
> just as a plain int wouldn't, despite the two types being distinct
> and not compatible.
>
Ok. I agree with your example. But 2 points:
- The representation of 'int' is discussed in much greater detail than
the representation of any pointer type. Pointer representations are
much more opaque and free for the implementation to decide upon.
- I don't think it makes practical sense to encode type information in
the padding bits of an 'int', but it certainly seems useful to encode
extra information in a pointer representation, since they are derived
types with abstract values.
Surely if, in
void somefunc(void) {
unsigned char c;
/* ... */
}
'c' is permitted to have a trap representation due to its "provenance,"
then it is especially convenient that pointer representations are
opaque, so "provenance" or other meta-data can be encoded directly. No?
>> It seems clear to me that size, alignment, argument promotion (none)
>> and format of 'struct foo *' and 'struct bar *' must be the same, but
>> I don't yet understand how that ties into compatible types nor into
>> defined behaviour, since
>>
>> "Certain object representations need not represent a value of the
>> object type. If the stored value of an object has such a
>> representation and is read by an lvalue expression that does not have
>> character type, the behavior is undefined. If such a representation is
>> produced by a side effect that modifies all or any part of the object
>> by an lvalue expression that does not have character type, the
>> behavior is undefined.41) Such a representation is called a trap
>> representation."
>>
>> Why can a valid 'struct foo *' value's representation represent a
>> valid 'struct foo *' value but not a trap for a 'struct bar *'? For
>> example, it might be useful to trap a 'const struct baz *'
>> representation read into a 'struct baz *' object. A single bit in the
>> representation would be sufficient for that. The representation would
>> be the same, wouldn't it?
>
> No. I expect you're thinking of "representation" as more or less
> synonymous with "format",
Yes, you are right about that.
> but representation means more than that.
> The representation of a type is the mapping from the bits (ie, the
> byte values of the object representation) to values in the type's
> abstract value space, including trap values. If two types have
> the same representation, that means the two mappings produce
> corresponding values (ie, for each object representatioon) in the
> two abstract value spaces. For C, corresponding values are what
> would be produced by conversion between the two types in question.
> In other words, if types A and B have the same representation,
> then copying the bytes (eg, with memcpy()) from an 'A a;' into a
> 'B b;' must give the same results as 'b = (B) a;'. Any change in
> behavior between the two cases means the two representations are
> not the same.
I'm struggling to reconcile that with C99's 3.17p1 and 6.2.6.1. 3.17p1:
"value
precise meaning of the contents of an object when interpreted as
having a specific type"
I'm missing the part where it's possible for the same object
representation to represent the same value for two incompatible types,
since the value depends on the type.
Regarding conversion, 6.3p2 has that
"Conversion of an operand value to a compatible type causes no change
to the value or the representation."
Why mention both of them instead of simply "representation," if there's
a one-to-one correspondence between representation and value, given
compatible type? (Let alone incompatible types with the same
representation.)
Regarding pointer conversion, 6.3.2.3p1 has that
"For any qualifier q, a pointer to a non-q-qualified type may be
converted to a pointer to the q-qualified version of the type; the
values stored in the original and converted pointers shall compare equal."
Doesn't this explicitly hint that a 'const int *' value's representation
is permitted to be a trap representation for an 'int *', but not the
other way around? It seems convenient that such meta-data can be
directly encoded into the pointer representation, since pointer
representation is so opaque.
There's also p7:
"A pointer to an object or incomplete type may be converted to a
pointer to a different object or incomplete type. If the resulting
pointer is not correctly aligned57) for the pointed-to type, the
behavior is undefined. Otherwise, when converted back again, the result
shall compare equal to the original pointer. ..."
Doesn't this explicitly hint that it's not the most portable idea to do
anything much with a converted pointer other than to eventually convert
it back before using it? If I understand you correctly, there's no
conversion happening, as the value is simply becoming one in a different
type's value space, so there's no problem with p7.
Regarding your equivalence between the 'memcpy' and the cast for two
types with the same representation, 6.5.4p4 has that
"Preceding an expression by a parenthesized type name converts the
value of the expression to the named type. This construction is called a
cast.89) A cast that specifies no conversion has no effect on the type
or value of an expression."
If '(B) a' is already the same value as 'a' due to the types having the
same representation, then there is no conversion, right? If that's the
case, then the type of '(B) a' should be 'A'. Like 3.17p1, type and
value are once again tied together, so it seems to me that incompatible
types can have incompatible values.
HOWEVER, you said _corresponding_values_. So I'd ask: May a value in
the value space for type 'A' not have a corresponding, but invalid value
in the value space for type 'B'? If it may, then I fail to understand
why the original post's code is well-defined in C99 and C11.
> Accessing via type B using a union member access
> works the same way that the memcpy() would.
I absolutely agree with your equivalence between 'memcpy' and union
members. Also: Re-interpreting the object representation with something
like:
A * ptr;
(*((B **) &ptr));
(where types 'A' and 'B' have the same representation.)
> For pointers, there is the additional concern that the converted
> or corresponding value be a non-trap value in the abstract value
> space of the new pointer type. However, in the particular example
> here (ie, in the original posting, even though since disappeared
> in the subthread), we know the pointer conversions have to work
> because of the way the particular structs being pointed to are
> nested.
>
Ah, that answers my last question, above. But there's a bit of a jump
in the logic that I can't grasp, and that's why the nesting of the
structures in the original example has anything at all to do with the
corresponding pointer value having to work. Yes, I agree that the
original example's bounds are covered because of the nesting, but I
don't understand why that's the only important subject.
To back up a bit from the original example, 'char *' and 'void *' have
the same representation. Would you say that in:
void reinterpret(void) {
void * vp = &vp;
vp = (*((char **) &vp)) + 1;
}
the expression-statement has Standard-defined behaviour? I'm worried
about this example because an implementation might wish to represent
"the stride" of the pointer arithmetic, just as "Multi-Dimensional Array
Simulator"[1] does. Implicit and explicit conversions (like the
promotions, casts, equality and ternary semantics, etc.) seem to offer
all the protection we need, while re-interpretation does not.
- Shao Miller
[1] http://www.iso-9899.info/wiki/Code_snippets
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[union] Pointers to inherited structs are valid ? Maciej Labanowicz <m.labanowicz@gmail.com> - 2013-01-01 03:45 -0800
Re: [union] Pointers to inherited structs are valid ? Barry Schwarz <schwarzb@dqel.com> - 2013-01-01 17:59 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:18 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-01 21:06 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:45 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-02 19:56 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-03 08:28 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-03 15:31 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-03 20:55 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-03 21:00 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-04 12:56 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-04 12:59 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-06 20:00 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-07 00:47 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-06 23:06 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-07 04:03 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-07 08:25 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-13 10:34 -0800
Re: Off-Topic: Irritating Posting Patterns Shao Miller <sha0.miller@gmail.com> - 2013-01-13 16:00 -0500
Re: Off-Topic: Irritating Posting Patterns Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-14 12:27 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-07 07:41 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-12 14:52 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-13 15:19 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-14 12:04 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-14 18:52 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-16 00:01 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-16 05:43 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-16 09:01 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-16 18:32 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-16 17:32 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-16 20:57 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-17 07:55 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-17 16:47 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-18 08:41 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-18 15:53 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-18 17:38 -0800
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-19 02:31 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-18 23:15 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-19 20:03 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 02:19 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-20 07:57 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 15:25 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-20 23:58 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 21:30 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-21 02:53 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 00:05 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-21 16:31 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 14:07 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-21 21:05 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 17:13 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 16:11 -0800
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-22 04:59 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-22 01:05 -0500
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-22 14:53 +0000
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 08:38 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-21 20:53 -0800
Re: [union] Pointers to inherited structs are valid ? Philip Lantz <prl@canterey.us> - 2013-01-22 00:58 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 08:40 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-22 23:32 -0800
Re: [union] Pointers to inherited structs are valid ? Philip Lantz <prl@canterey.us> - 2013-01-23 23:21 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-24 04:53 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-25 10:49 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 08:25 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-22 23:41 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 13:32 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 17:46 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 07:43 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-22 16:07 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 14:15 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 14:31 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-22 21:32 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-23 17:17 -0500
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-23 19:49 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-23 18:55 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-24 11:01 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-24 14:11 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-22 17:51 -0800
Re: [union] Pointers to inherited structs are valid ? Philip Lantz <prl@canterey.us> - 2013-01-20 16:48 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 21:33 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-21 09:23 -0800
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-20 17:07 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-20 22:20 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-20 22:02 -0800
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-21 07:00 +0000
Re: [union] Pointers to inherited structs are valid ? James Kuyper <jameskuyper@verizon.net> - 2013-01-21 08:17 -0500
Re: [union] Pointers to inherited structs are valid ? Dr Nick <nospam-4@temporary-address.org.uk> - 2013-01-21 14:13 +0000
Re: [union] Pointers to inherited structs are valid ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-01-21 14:12 +0000
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 08:20 -0800
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-21 20:41 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 12:37 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 12:17 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 16:33 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-21 15:50 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-21 19:45 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-22 00:18 -0500
Re: [union] Pointers to inherited structs are valid ? Keith Thompson <kst-u@mib.org> - 2013-01-22 08:01 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-18 23:02 -0500
Re: [union] Pointers to inherited structs are valid ? Philip Lantz <prl@canterey.us> - 2013-01-19 01:28 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-19 12:08 -0500
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-21 09:27 -0800
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 12:46 -0500
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-21 20:48 +0000
Re: [union] Pointers to inherited structs are valid ? Geoff <geoff@invalid.invalid> - 2013-01-21 18:52 -0800
Re: [union] Pointers to inherited structs are valid ? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-22 04:07 +0000
Re: [union] Pointers to inherited structs are valid ? Shao Miller <sha0.miller@gmail.com> - 2013-01-21 23:15 -0500
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-16 10:59 -0800
Re: [union] Pointers to inherited structs are valid ? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:34 -0800
csiph-web