Re: Sugestions for runtime polymorphism

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.lang.c
Subject	Re: Sugestions for runtime polymorphism
Date	2016-09-25 18:39 +0200
Organization	A noiseless patient Spider
Message-ID	<ns8ujt$qi8$1@dont-email.me> (permalink)
References	(17 earlier) <87twd5fitb.fsf@bsb.me.uk> <ns67c3$25n$1@dont-email.me> <87h995f4lm.fsf@bsb.me.uk> <ns89ok$lj2$1@dont-email.me> <c7e2e2a0-678b-292c-08db-0feab65420fe@verizon.net>

Show all headers | View raw

On 25/09/16 17:48, James R. Kuyper wrote:
> On 09/25/2016 06:43 AM, David Brown wrote:
> ...
>> My test on gcc.godbolt.org is here:
>>
>> <https://gcc.godbolt.org/#compilers:!((compiler:g520,options:'-O2+-Wall+-Wextra+-x+c',sourcez:FAAjGIEsDsGMBsCuATApiAPAZwC7JjgHQAWAfKGCFHEmprgE4wDmJ5lVMCK62e8kAEZsKELrV658AexGiQOAJ4AHVGgBmIeNOjMtOvQBUAjAG55S1RpAEAbABYA%2BjhCGATOY7gNMdCYBiALKGIABEAKTw8Mih8t6o6r6uxgBqAIIAMgCqAKIgxgAMBXE%2B0H5u6dl5bkXA8iYggvAAhsQAzAAUAG7SkMggAFTKxgA0ID19g8puAJTyAN7yYA0DOMbKY6vrHkuuboM4bsqeHMkKqAC2x3WnCusgALwgwycch8qPzzu3Wx9PJpVcqZKAB6EEgADqTBw6GaWGSu1WR0%2B7kBOWBYDBkOhsPh7l2MKunyRx1uWIASqhmv04XsCdtPh0TAMZu8MViUpAsEJ4OUFNIzspetAYQwQLAdF1UAxuTpEWtpp9CaSOFioZAYSBaSZdgxUDhEAxoAd1hjVeDKdStXjjPIAL43SgNGG4ToTZBzDiLW7uqafC7NKLSWAdbkAL1Q0k0TOMMxAAGoQOHI9H3DMZq8ncYQHqsIh4C4nk1Wp0NsoM7t1HrUB1y5mwHqDUac6g8wXMw6OAQQAGYN1eh6FrsGrn84Xzq6OhXbsomCL1B1QoZiOhRwWbPDQskgoYxmucNPTo3DcaCmbKPagAA%3D%3D)),filterAsm:(commentOnly:!t,directives:!t,labels:!t),version:3>
>>
>>
>> I changed the values of T1VALUE and T2VALUE to 100 and 200, to make it
>> easier to spot them in the resulting assembly code.
>>
>>
>> The details of the standards here is getting beyond me.  When you and
>> James both think the answer should be 1, and 2 is not allowed, ...
>
> I never said what the answer should be. Ben said gcc gave him 2 for all
> optimization levels. I'm not sure why you think we've claimed the answer
> should be 1.


My apologies - I meant to say "think the answer should be /2/, and /1/ 
is not allowed".  That was a rather unhelpful mixup on my part!

I should also have written "I think they think...", since it was my 
interpretation of what you wrote, rather than your exact words.

>
> 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


>         *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
> /* *t1p has the type T1, matching the current effective type of that
> memory. As a result, there's no problem retrieving T2VALUE from that
> memory and returning it as the value of blah3.
> */
>
> test3:
>         T1 result = blah3(p,p);
> /* result now contains T2value */
>         free(p);
>         return result;
> /* T2VALUE is now returned as the value of test3. */
>
> main:
>         T1 result = test3();
> /* result now has the value T2VALUE */
>         printf("The result is " T1FMT, result);
> /* Which is then printed out */
>
> T2VALUE is 2. By what argument would anyone claim that a value of 1
> could be printed out?

It is the result gcc gives.

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").  Or at least, I would prefer it if gcc had this as 
documented implementation-dependent behaviour.

The question is, is this a bug in gcc?  Or is it just a case of 
optimising from undefined behaviour in a way that might surprise people?

>
>> ... then I am
>> far from confident about 2 being allowable - you are both more better at
>> "language lawyering" than me.  But I do know that gcc will do this sort
>> of transformation in practice, and in real code - you need to be very
>> careful in mixing pointers to different integer types even when you know
>> they are the same underlying hardware types.
>
> At no point does this code do anything which relies upon the assumption
> that long long and int64_t are the same underlying type. It would work
> equally well if T2 were any integer type other than _Bool. It would even
> work if T2 were a floating point type, except for the theoretical
> possibility of floating point roundoff errors, but in practice that
> would never happen with integers smaller than 1.0/FLT_EPSILON.

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