Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: Sugestions for runtime polymorphism
Date: Sat, 24 Sep 2016 13:58:26 -0700
Organization: None to speak of
Lines: 110
Message-ID: <lnfuopuia5.fsf@kst-u.example.com>
References: <b0659440-88ee-4d0f-861e-d5bb1cd0890d@googlegroups.com> <376d191c-1ad2-47f6-b8ed-0811ecc7babc@googlegroups.com> <nrdqgg$mu4$1@dont-email.me> <52493fe0-da8d-46ca-b38d-d811e3fad940@googlegroups.com> <nreqg5$7b7$1@dont-email.me> <62822054-7d11-49da-8a61-134ce2639126@googlegroups.com> <nresr3$g2s$1@dont-email.me> <666af99b-9b6b-4f1a-a1a3-498ab48d6f44@googlegroups.com> <5be0e169-cd80-4785-b2c8-934e71cf1164@googlegroups.com> <nrh3f1$m25$1@dont-email.me> <e06bdc46-44cb-418e-8783-94c3147871f3@googlegroups.com> <8e6459ac-a363-487b-96d8-3585fad04dd5@googlegroups.com> <7ee4b7c9-5d16-40bf-acb0-738ae7e3bc86@googlegroups.com> <9179e698-fe07-416c-a885-cca3f6b5d606@googlegroups.com> <kfn8tukfhmp.fsf@x-alumni2.alumni.caltech.edu> <ns0i2u$nb8$1@dont-email.me> <09902938-21f0-4c45-9d71-bde7b5398bd2@googlegroups.com> <lnvaxnvkp9.fsf@kst-u.example.com> <233fb759-60f4-4113-ba1c-0949c8fdb924@googlegroups.com> <ns2mq7$bqh$1@dont-email.me> <58c2a8d6-5609-458e-93f9-0811123a96ff@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="22984"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19LZIX2ez7osguBXDfcjHwJ"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:d6LlBjLTDdLl9aoc4V8KPEkstbo= sha1:IXkrUeQxnqebx1QYSChZuxcSfDI=
Xref: csiph.com comp.lang.c:93994

supercat@casperkitty.com writes:
> On Friday, September 23, 2016 at 2:49:43 AM UTC-5, David Brown wrote:
>> On 22/09/16 18:52, supercat wrote:
>> Your first claim was that gcc (6.2) incorrectly handles code in a way
>> that goes against the unambiguous rules of the standards.  This is a
>> serious allegation, and should be backed up with concrete examples and
>> bug reports.  The gcc team take all "incorrect code generation" bugs
>> extremely seriously.  And while /you/ might not use gcc, millions of
>> others do use it.  Someone here (such as me) will happily file a bug
>> report if you have a specific bug.
>> 
>> But now you have modified back to your usual "gcc optimises too well -
>> it follows the requirements of the real C standards, rather than my
>> imaginary specifications of thirty years ago".
>> 
>> So which is it?  Can you give us a concrete example of buggy code, that
>> we can paste into <http://gcc.godbolt.org/#> and compare results with
>> different gcc versions and different compilers?  You can't just refer to
>> "I've posted about it before" - you have posted hundreds or thousands of
>> snippets in this group.
>
>     #include <stdint.h>
>     #include <string.h>
>     #include <stdlib.h>
>     #include <stdio.h>
>
>     typedef long long T1;
>     typedef int64_t T2;
>     #define T1FMT "%lld"
>     #define T1VALUE 1
>     #define T2VALUE 2
>
>     T1 blah3(void *p1, void *p2)
>     {
>       T1 *t1p, *t1p2;
>       T2 *t2p;
>       T1 temp;
>
>       t1p = p1;
>       t2p = p2;
>       *t1p = T1VALUE;   // Write as T1
>       *t2p = T2VALUE;   // Write as T2
>       temp = *t2p;      // Read as T2
>       t1p2 = (T1*)t2p;  // Visible T2 to T1 pointer conversion
>       *t1p2 = temp;     // Write as T1
>       return *t1p;      // Read as T1
>     }
>
>     T1 test3(void)
>     {
>       void *p = malloc(sizeof (T1) + sizeof (T2));
>       T1 result = blah3(p,p);
>       free(p);
>       return result;
>     }
>     int main(void)
>     {
>       T1 result = test3();
>       printf("The result is " T1FMT, result);
>       return 0;      
>     }
[...]
> So there's a sample of buggy code.  Similar thing can happen if there are
> two structure types that have the same representation.

I found that the typedefs and macros made the code difficult to read;
YMMV.

Here's my version, which I believe is equivalent -- assuming
that long and long long have the same size and representation,
and that int64_t is a typedef for long.  (I also added a newline
to the output.)

On my x86_64 system, using gcc 6.2.0, I get "The result is 2"
with -O0 and -O1, and "The result is 1" with -O2 and -O3.

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

long long func1(void *p1, void *p2) {
    long long *llp1 = p1;
    long *lp = p2;
    *llp1 = 1;             // Write as long long
    *lp = 2;               // Write as long
    long long temp = *lp;  // Read as long
    long long *llp2 = (long long*)lp;  // Visible long to long long
    pointer conversion
    *llp2 = temp;          // Write as long long
    return *llp1;          // Read as long long
}

long long func2(void) {
    void *p = malloc(sizeof (long long) + sizeof (long));
    long long result = func1(p,p);
    free(p);
    return result;
}

int main(void) {
    assert(sizeof (long) == sizeof (long long));
    printf("The result is %lld\n", func2());
}

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"