Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Sugestions for runtime polymorphism |
| Date | 2016-09-25 23:25 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <ns9fcj$orn$1@dont-email.me> (permalink) |
| References | (17 earlier) <87h995f4lm.fsf@bsb.me.uk> <ns89ok$lj2$1@dont-email.me> <c7e2e2a0-678b-292c-08db-0feab65420fe@verizon.net> <ns8ujt$qi8$1@dont-email.me> <a48fe888-76ca-6342-34f3-26952ab98bef@verizon.net> |
On 25/09/16 19:14, James R. Kuyper wrote:
> On 09/25/2016 12:39 PM, David Brown wrote:
>> On 25/09/16 17:48, James R. Kuyper wrote:
> ...
>>> Here's the original code that I was talking about, in order of
>>> execution:
>>>
>>> main:
>>> ... test3();
>>>
>>> test3:
>>> void *p = malloc(sizeof (T1) + sizeof (T2));
>>> /* p now points at a buffer; for convenience I'll refer to that buffer
>>> using 'p' even in contexts where 'p' is not in scope.
>>> */
>>> ... blah3(p,p);
>>>
>>> blah3:
>>> T1 blah3(void *p1, void *p2)
>>> {
>>> /* p1 and p2 are both set equal to p */
>>> t1p = p1;
>>> t2p = p2;
>>> /* t1p and t2p both point at the same location as p */
>>> *t1p = T1VALUE; // Write as T1
>>> /* The sizeof(T1) bytes starting at p now contain a representation of
>>> T1VALUE as an object of type T1, which is now the effective type of
>>> that memory.
>>> */
>>> *t2p = T2VALUE; // Write as T2
>>> /* The sizeof(T2) bytes starting at p now contain a representation of
>>> T2VALUE as an object of type T2, which is now the effective type of
>>> that memory.
>>> */
>>> temp = *t2p; // Read as T2
>>> /* Since *t2p has the type T2, which matches the effective type of that
>>> memory, there is no problem reading the value T2VALUE from that
>>> memory, which is then stored in temp.
>>> */
>>
>> OK so far...
>>
>>> t1p2 = (T1*)t2p; // Visible T2 to T1 pointer conversion
>>> /* I missed this point: conversion from T2* to T1* is allowed, since
>>> this particular pointer is guaranteed to be correctly aligned for
>>> either type. However, technically, the standard says nothing about
>>> where t1p2 actually points. In principle, the only thing that is
>>> guaranteed about the value of t1p2 is that if you convert it back to
>>> T2*; the result will compare equal to t2p. For instance, the forward
>>> conversion could add 1024 bytes to the position, so long as the reverse
>>> conversion subtracted the same amount.
>>> In practice, on virtually every real world implementation of C, t1p2
>>> will point at the same location as all of the other object pointers in
>>> this program, and I believe it was the committee's intent that this be
>>> true. However, I haven't managed to convince anyone in authority that
>>> there's any need to change the wording to reflect that intent.
>>> */
>>
>> gcc appears to be optimising on the basis that the only defined
>> behaviour for t1p2 is that you can covert it back to a T2* and get the
>> same pointer as t2p. The assembly it generates is (with my comments):
>>
>> blah3:
>> movq $1, (%rdi) // Store 1 in *t1p
>> movl $1, %eax // The return value 1
>> movq $2, (%rsi) // Store 2 in *t2p
>> ret
>>
>> test3:
>> movl $1, %eax
>> ret
>
> I doubt that the t1p2 conversion is the justification used by gcc for
> generating this code. That's a purely pedantic issue that bothers only
> me - it's not something real implementations handle in any fashion
> different from the committee's intent.
>
> I've long assumed that the purpose of the anti-aliasing rules was to
> gave implementations considerable freedom to reorder code using pointers
> to different types, if the code consisted of a read from one type and a
> write to a different type, if that pair of types was not connected by
> one of the rules listed in 6.5p7.
> However, after analyzing the code above, I realized that the
> implementation's freedom is seriously restricted by the possibility that
> the pointers point at dynamically allocated memory, due to the fact that
> the effective type can change with each write. In fact, I'm wondering if
> the anti-aliasing rules give implementations any freedom at all to
> reorder such code - could I be misunderstanding either 6.5p6 and p7?
>
> The optimization you show above would be permitted if the two pointers
> didn't point at dynamically allocated memory, and I'm wondering if gcc's
> mistake was in failing to consider that possibility.
I know /I/ failed to consider the effect of dynamically allocated
memory. It is possible that gcc does so too, especially since it has
eliminated the dynamic allocation.
>
>>> *t1p2 = temp; // Write as T1
>>> /* T2VALUE is converted to type T1, and stored in the sizeof(T1) bytes
>>> starting at p. The effective type of that memory is now T1.
>>> */
>>> return *t1p; // Read as T1
>
> ...
>>> T2VALUE is 2. By what argument would anyone claim that a value of 1
>>> could be printed out?
>>
>> It is the result gcc gives.
>
> Not on Ben's machine. Have the two of you resolved which of you is using
> the later version of gcc?
Yes. He had some other flags that affected the compilation.
>
>> This is either a valid result due to the conversion of pointer types
>> mentioned above (and claims about "virtually every real world
>> implementation of C" are simply incorrect, because gcc is a pretty major
>> exception), or gcc has a bug here.
>>
>> To be clear, I would be happier if gcc gave 2 here - the same result as
>> other compilers on <gcc.godbolt.org>, and the result one would
>> reasonably expect. ...
>
>> ... I would prefer if the C standards said that types
>> such as "long", "long long", and "int64_t" were all considered
>> "compatible" if they are all the same size (and similarly for "int",
>> "long", "int32_t"). ...
>
> The C standard currently allows integer types with the same size and
> same signedness to use different byte orders, and even different bit
> orders (it allows this by the simple expedient of failing to specify
> anything relevant about the byte order or bit order). I believe this
> freedom is intentional, though I'm not sure if any real-world
> implementation takes advantage of this freedom. I would oppose mandating
> that they be compatible.
If an implementation had different byte orderings for two equally sized
types, then I would happily agree that pointers should be incompatible.
(I would also be pleased to see such a feature - sometimes in my
programming I need to deal with non-native byte ordering. gcc now has
support for non-native byte ordering in structs, which is nice.)
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 12:01 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 13:15 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 13:27 -0700
Re: Sugestions for runtime polymorphism Richard Heathfield <rjh@cpax.org.uk> - 2016-09-14 21:50 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 14:20 -0700
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-14 17:32 -0400
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-14 16:30 -0700
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-14 17:54 -0400
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 17:34 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 17:58 -0700
Re: Sugestions for runtime polymorphism Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-14 19:50 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 05:03 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-15 10:43 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 05:29 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-15 19:49 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 11:58 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-15 20:29 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 14:00 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 07:27 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-16 16:34 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-16 09:36 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-20 12:59 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-20 14:08 -0700
Re: Sugestions for runtime polymorphism Ian Collins <ian-news@hotmail.com> - 2016-09-21 15:53 +1200
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-21 07:38 -0700
Re: Sugestions for runtime polymorphism Ian Collins <ian-news@hotmail.com> - 2016-09-23 09:12 +1200
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-21 05:26 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-21 05:35 -0700
Re: Sugestions for runtime polymorphism Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-21 06:01 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 01:44 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-22 13:16 +0100
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-22 08:02 -0700
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-22 11:44 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-22 09:52 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-23 09:49 +0200
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-23 07:55 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-24 16:29 +0200
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-24 15:56 +0100
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-24 17:50 +0200
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-24 13:45 -0400
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-24 11:26 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:38 -0700
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-24 21:03 +0100
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 12:43 +0200
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-25 11:48 -0400
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 18:39 +0200
Re: Sugestions for runtime polymorphism "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-25 13:14 -0400
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-25 13:47 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:39 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 23:25 +0200
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-25 13:10 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-25 12:55 -0700
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 20:38 +0100
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 23:20 +0200
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 07:15 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-28 21:29 +0200
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-24 10:52 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-24 10:33 -0700
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-25 12:46 +0200
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-24 13:58 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 04:46 -0700
Re: Sugestions for runtime polymorphism Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-24 00:07 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 08:52 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-23 09:56 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 12:00 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 08:45 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-22 09:36 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 12:06 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-23 15:29 -0700
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 07:56 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-30 10:54 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 11:18 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-30 19:26 +0100
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-30 12:41 -0700
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-30 21:07 +0100
Re: Sugestions for runtime polymorphism Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-30 23:30 -0700
Re: Sugestions for runtime polymorphism Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 11:35 +0100
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-10-01 14:44 -0700
Re: Sugestions for runtime polymorphism Richard Heathfield <rjh@cpax.org.uk> - 2016-09-14 22:56 +0100
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-15 13:19 +0200
Re: Sugestions for runtime polymorphism James Kuyper <jameskuyper@verizon.net> - 2016-09-15 08:07 -0400
Re: Sugestions for runtime polymorphism David Brown <david.brown@hesbynett.no> - 2016-09-15 14:24 +0200
Re: Sugestions for runtime polymorphism Richard Heathfield <rjh@cpax.org.uk> - 2016-09-15 15:34 +0100
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-15 05:10 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-15 09:12 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-14 23:32 +0100
Re: Sugestions for runtime polymorphism "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-14 17:35 -0700
Re: Sugestions for runtime polymorphism Ian Collins <ian-news@hotmail.com> - 2016-09-15 16:24 +1200
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-15 10:31 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-14 22:53 +0100
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-14 16:56 -0700
Re: Sugestions for runtime polymorphism supercat@casperkitty.com - 2016-09-14 15:58 -0700
Re: Sugestions for runtime polymorphism Keith Thompson <kst-u@mib.org> - 2016-09-14 18:49 -0700
Re: Sugestions for runtime polymorphism luser droog <luser.droog@gmail.com> - 2016-09-14 14:17 -0700
Re: Sugestions for runtime polymorphism Thiago Adams <thiago.adams@gmail.com> - 2016-09-14 14:25 -0700
Re: Sugestions for runtime polymorphism luser droog <luser.droog@gmail.com> - 2016-09-14 14:40 -0700
Re: Sugestions for runtime polymorphism luser droog <luser.droog@gmail.com> - 2016-09-14 14:57 -0700
Re: Sugestions for runtime polymorphism BartC <bc@freeuk.com> - 2016-09-14 23:10 +0100
Re: Sugestions for runtime polymorphism Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 11:23 -0700
csiph-web