Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #122662 > unrolled thread

Re: Equal yet different pointers

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 11:29 +0100
    Re: Equal yet different pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-11-16 03:01 -0800
      Re: Equal yet different pointers "Bill Davy" <Bill@XchelSys.co.uk> - 2017-11-16 11:03 +0000
      Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 13:55 +0100
        Re: Equal yet different pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-11-16 06:44 -0800
          Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 14:49 +0000
            Re: Equal yet different pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-11-16 08:28 -0800
          Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 16:46 +0100
        Re: Equal yet different pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-16 12:29 -0500
          Re: Equal yet different pointers Nick Bowler <nbowler@draconx.ca> - 2017-11-17 22:47 +0000
            Re: Equal yet different pointers Richard Damon <Richard@Damon-Family.org> - 2017-11-18 17:03 -0500
    Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 11:09 +0000
      Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 11:14 +0000
      Re: Equal yet different pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-16 03:41 -0800
        Rick's neuroses (Was: Equal yet different pointers) gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-16 12:11 +0000
          Re: Rick's neuroses (Was: Equal yet different pointers) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-16 04:30 -0800
            Re: Rick's neuroses (Was: Equal yet different pointers) David Brown <david.brown@hesbynett.no> - 2017-11-16 14:52 +0100
              Obscure references (Was: Rick's neuroses (Was: Equal yet different pointers)) gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-19 12:32 +0000
                Re: Obscure references Noob <root@127.0.0.1> - 2017-11-20 11:08 +0100
                  Re: Obscure references David Brown <david.brown@hesbynett.no> - 2017-11-20 12:36 +0100
      Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 14:45 +0100
        Re: Equal yet different pointers Keith Thompson <kst-u@mib.org> - 2017-11-16 08:55 -0800
          Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 17:09 +0000
            Re: Equal yet different pointers Keith Thompson <kst-u@mib.org> - 2017-11-16 09:33 -0800
          Re: Equal yet different pointers Gareth Owen <gwowen@gmail.com> - 2017-11-16 19:20 +0000
            Re: Equal yet different pointers Keith Thompson <kst-u@mib.org> - 2017-11-16 11:36 -0800
              Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 22:50 +0100
                Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-16 14:34 -0800
                  Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 10:44 +0100
                    Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-17 08:23 -0800
                      Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 19:13 +0100
                        Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-17 16:45 -0800
                          Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-18 07:30 +0000
          Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 22:25 +0100
            Re: Equal yet different pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-16 23:11 +0000
              Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-16 15:47 -0800
              Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 10:49 +0100
        Re: Equal yet different pointers Gareth Owen <gwowen@gmail.com> - 2017-11-16 19:20 +0000
          Re: Equal yet different pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-16 11:26 -0800
          Re: Equal yet different pointers gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-16 22:22 +0000
            Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 23:09 +0000
              Re: Equal yet different pointers gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-17 08:50 +0000
                Re: Equal yet different pointers Gareth Owen <gwowen@gmail.com> - 2017-11-17 17:42 +0000
                  Re: Equal yet different pointers gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-17 19:35 +0000
        Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 23:34 +0000
          Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-16 15:58 -0800
          Re: Equal yet different pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-17 00:57 +0000
          Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 12:32 +0100
            Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-17 12:31 +0000
              Re: Equal yet different pointers mark.bluemel@gmail.com - 2017-11-17 07:23 -0800
              Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 17:14 +0100
                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 00:12 +0000
                  Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-18 13:39 +1300
                    Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 01:39 +0000
                      Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-18 14:42 +1300
                        Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 02:01 +0000
                          Re: Equal yet different pointers Melzzzzz <Melzzzzz@zzzzz.com> - 2017-11-18 02:07 +0000
                          Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-18 15:35 +1300
                            Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 11:23 +0000
                              Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-19 12:02 +1300
                                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 23:25 +0000
                                  Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-19 13:44 +1300
                                    Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-19 01:05 +0000
                                      Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-19 14:30 +1300
                                        Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-19 01:48 +0000
                                          Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-19 16:21 +1300
                                            Re: Equal yet different pointers Reinhardt Behm <rbehm@hushmail.com> - 2017-11-19 11:44 +0800
                                            Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-19 10:10 +0000
                                              Re: Equal yet different pointers mark.bluemel@gmail.com - 2017-11-20 00:52 -0800
                                Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-19 23:27 +0100
                                  Re: Equal yet different pointers Richard Damon <Richard@Damon-Family.org> - 2017-11-19 22:48 -0500
                                  Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-20 16:52 +1300
      Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 14:28 +0000
        Re: Equal yet different pointers Barry Schwarz <schwarzb@dqel.com> - 2017-11-16 07:10 -0800
          Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 16:51 +0100
            Re: Equal yet different pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-16 12:57 -0500
        Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-16 08:03 -0800
        Re: Equal yet different pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-16 12:38 -0500
          Re: Equal yet different pointers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-16 20:13 +0100
            Re: Equal yet different pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-16 14:29 -0500
      Re: Equal yet different pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-11-16 15:57 +0000
        Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 16:07 +0000
          Re: Equal yet different pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-11-16 19:01 +0000
            Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 19:14 +0000
              Re: Equal yet different pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-11-16 19:47 +0000
        Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 23:08 +0000
          Re: Equal yet different pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-17 00:33 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#122679

On 16/11/17 12:09, bartc wrote:
> On 16/11/2017 10:29, David Brown wrote:
>> On 16/11/17 11:00, Stefan Ram wrote:
>>>    I did not invent this program, I just read it in an article
>>>    and then typed it in from my memory:
>>>
>>>    main.c
>>>
>>> #include <stdio.h>
>>> #include <string.h>
>>>
>>> int main()
>>> { int i = 1; int j = 2;
>>>    int * p = &i + 1; int * q = &j;
>>>    if( !memcmp( &p, &q, sizeof( p )))
>>>    { *p = 3; printf( "%d %d\n", *p, *q ); }}
>>>
>>>    transcript
>>>
>>> 3 2
>>>
>>>    NB: The memcmp compares the pointers themselves,
>>>    not their pointees. p is only dereferenced after
>>>    it has been established that it is memcmp-equal
>>>    to q, which is a valid pointer.
>>>
>>
>> That seems entirely reasonable to me.  You are asking the compiler to do
>> something undefined - take the address of a single int, and pretend that
>> it is an array of at least 2 ints.  The compiler knows that makes no
>> sense, and ignores your attempt to write to j via *p.
>>
>> Garbage in, garbage out.
> 
> You seem to be so in love with gcc that it apparently can do no wrong.
> 

It is the way C is defined.  Should I complain about a C compiler that
compiles C code according to the rules of C?

gcc /does/ do something wrong here - it accepts this program without
warnings, even with -Wall -Wextra.  So I do have something to complain
about here with gcc.

> I ran the program below on a range of compilers, and the results were as
> expected, and consistent, on all of them except gcc.

There is no "expected" result.  The C standards are quite clear here -
accessing data through *p in this code is undefined behaviour.  There
can be no "expected" behaviour - it is undefined.

I changed the code to a function that returns *q, rather than using
printf, and looked at the generated assembly.  With optimisation, gcc
does the equivalent of "return 2" - it removes all the unnecessary code
that has no particular meaning, and gives the optimal object code.  I
like that in a compiler.  clang does the same.  Intel's icc generates a
bit more mess, so that it actually does the memcmp (using an inlined
version), but the result will be 2 as far as I can see.  MSVC generates
the same code as gcc.  I don't have any minimalistic compilers on hand
to see how they do - I will accept your word that they give 3.  As the
result is undefined, 3 is as good an answer as 2 - but no better.

C is defined by its standards - and code that is undefined by those
standards (or additional standards, including behaviour defined by the
implementation) has no meaning.  You can't judge the "right"
interpretation of meaningless code based on a popularity contest -
especially not when you mainly use limited little tools.

> 
> I think you ought to look around for a new one, because that one can't
> be relied up to do what you want and regardless of optimisation setting.

I don't rely on gcc to do what I /want/.  I rely on it to do what I tell
it.  I rely on my own skill as a programmer, my coding standards, my
development tools, and code reviews with my colleagues, to ensure that
what I tell the compiler to do is what I want it to do.

If you think it is the compiler's job to read your mind and figure out
what you want it to do, then you are in the wrong profession.


> 
> All tests were for x64 and with optimisation either on or off (if the
> compiler had such a setting). Only gcc -O3 gave the unexpected result:
> 

I tested this, and looked at the generated assembly:

#include <string.h>

int foo(void)
{
    int i = 1;
    int j = 2;
    int * p = &i + 1;
    int * q = &j;
    if (!memcmp(&p, &q, sizeof(p))) {
        *p = 3;
        return *q;
    }
    return *q;
}

gcc with -O1 upwards gives:

foo():
        mov     eax, 2
        ret

MSVC does the same at -O2, and as noted icc with optimisation generates
messy code which AFAICS also returns 2.

> Pelles C          p2==q  3 3
> lccwin64          p2==q  3 3
> DMC (32-bit)      p1==q  3 3
> TCC               p2==q  3 3
> MCC (mine)        p2==q  3 3
> MSVC**            -nothing-     (in C++ mode; &i, &j differ by 12 bytes)
> 
> gcc -O0           p2==q  3 3
> gcc -O3           p1==q  3 2
> 
> --------------------------------------
> 
> #include <stdio.h>
> #include <string.h>
> 
> int main()
> { int i = 1;
>   int j = 2;
>   int *p1 = &i + 1;
>   int *p2 = &i - 1;
>   int *q = &j;
> 
>   if(!memcmp( &p1, &q, sizeof( p1 ))) {
>     *p1 = 3;
>     printf("p1==q %d %d\n", *p1, *q );
>   }
>   if(!memcmp( &p2, &q, sizeof( p2 ))) {
>     *p2 = 3;
>     printf("p2==q %d %d\n", *p2, *q );
>   }
> 
>   printf("p1=%p\n",p1);
>   printf("p2=%p\n",p2);
>   printf("q=%p\n",q);
> }
> 
> --------------------------------------
> 
> (** I accidentally deleted the hello.c 'solution' I used to test C
> programs with VS2017. Someone kindly posted instructions here on how to
> set up VS to compile C code, but I can't find them; a link to the
> message or new instructions would be appreciated.)
> 

[toc] | [prev] | [next] | [standalone]

#122722

David Brown <david.brown@hesbynett.no> writes:
[...]
>>> On 16/11/17 11:00, Stefan Ram wrote:
>>>>    I did not invent this program, I just read it in an article
>>>>    and then typed it in from my memory:
>>>>
>>>>    main.c
>>>>
>>>> #include <stdio.h>
>>>> #include <string.h>
>>>>
>>>> int main()
>>>> { int i = 1; int j = 2;
>>>>    int * p = &i + 1; int * q = &j;
>>>>    if( !memcmp( &p, &q, sizeof( p )))
>>>>    { *p = 3; printf( "%d %d\n", *p, *q ); }}
>>>>
>>>>    transcript
>>>>
>>>> 3 2
[...]

> gcc /does/ do something wrong here - it accepts this program without
> warnings, even with -Wall -Wextra.  So I do have something to complain
> about here with gcc.

Why do you expect a warning?  There may or may not be undefined
behavior, but as far as I can tell no diagnostic is required.

For example,
    int *p = &i = 1;
is valid; the object i can be treated as a single element array, and p
points just past the end of it.  Normally dereferencing p would have
undefined behavior (which a compiler could detect only if it does data
flow analysis).

I'll have more to say in a followup to the original post.

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

[toc] | [prev] | [next] | [standalone]

#122725

On Thu, 16 Nov 2017 08:55:42 -0800
Keith Thompson <kst-u@mib.org> wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
> >>> On 16/11/17 11:00, Stefan Ram wrote:
> >>>>    I did not invent this program, I just read it in an article
> >>>>    and then typed it in from my memory:
> >>>>
> >>>>    main.c
> >>>>
> >>>> #include <stdio.h>
> >>>> #include <string.h>
> >>>>
> >>>> int main()
> >>>> { int i = 1; int j = 2;
> >>>>    int * p = &i + 1; int * q = &j;
> >>>>    if( !memcmp( &p, &q, sizeof( p )))
> >>>>    { *p = 3; printf( "%d %d\n", *p, *q ); }}
> >>>>
> >>>>    transcript
> >>>>
> >>>> 3 2
> [...]
> 
> > gcc /does/ do something wrong here - it accepts this program without
> > warnings, even with -Wall -Wextra.  So I do have something to complain
> > about here with gcc.
> 
> Why do you expect a warning?  There may or may not be undefined
> behavior, but as far as I can tell no diagnostic is required.
> 
> For example,
>     int *p = &i = 1;

                  ^
                  +  instead of  =

> is valid; the object i can be treated as a single element array, and p
> points just past the end of it.  Normally dereferencing p would have
> undefined behavior (which a compiler could detect only if it does data
> flow analysis).

[toc] | [prev] | [next] | [standalone]

#122731

Spiros Bousbouras <spibou@gmail.com> writes:
> On Thu, 16 Nov 2017 08:55:42 -0800
> Keith Thompson <kst-u@mib.org> wrote:
[...]
>> Why do you expect a warning?  There may or may not be undefined
>> behavior, but as far as I can tell no diagnostic is required.
>> 
>> For example,
>>     int *p = &i = 1;
>
>                   ^
>                   +  instead of  =

Yes, thank you.

>> is valid; the object i can be treated as a single element array, and p
>> points just past the end of it.  Normally dereferencing p would have
>> undefined behavior (which a compiler could detect only if it does data
>> flow analysis).

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

[toc] | [prev] | [next] | [standalone]

#122749

Keith Thompson <kst-u@mib.org> writes:

>> gcc /does/ do something wrong here - it accepts this program without
>> warnings, even with -Wall -Wextra.  So I do have something to complain
>> about here with gcc.
>
> Why do you expect a warning?  There may or may not be undefined
> behavior, but as far as I can tell no diagnostic is required.

Because some people have expectations that extend beyond the C standard?
I appreciate that the holy standard (peace be upon it) is your sole
point of reference in all things, but most people quite like that GCC
sometimes give diagnostics for dangerous or undefined constructs, even
when the standard says they're not required.

Its not unreasonable to expect one in a trivial case of UB like this.

[toc] | [prev] | [next] | [standalone]

#122754

Gareth Owen <gwowen@gmail.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>>> gcc /does/ do something wrong here - it accepts this program without
>>> warnings, even with -Wall -Wextra.  So I do have something to complain
>>> about here with gcc.
>>
>> Why do you expect a warning?  There may or may not be undefined
>> behavior, but as far as I can tell no diagnostic is required.
>
> Because some people have expectations that extend beyond the C standard?
> I appreciate that the holy standard (peace be upon it) is your sole
> point of reference in all things, but most people quite like that GCC
> sometimes give diagnostics for dangerous or undefined constructs, even
> when the standard says they're not required.
>
> Its not unreasonable to expect one in a trivial case of UB like this.

I was replying to David Brown; please don't snip attributions.  I'm
still curious why he expects a warning, and in particular whether he
thinks one is required.

I don't believe this is a trivial case of UB.  I'm not even convinced
that there's any undefined behavior.

Again, here's the code:

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

    int main()
    { int i = 1; int j = 2;
       int * p = &i + 1; int * q = &j;
       if( !memcmp( &p, &q, sizeof( p )))
       { *p = 3; printf( "%d %d\n", *p, *q ); }}

p points just past the end of an object (which is treated as a
1-element array).  Normally dereferencing such a pointer would have
undefined behavior, but in this case it's done only after verifying
that that pointer is bitwise equal to a pointer to another object.
There are some sticky issues in the relationship between bitwise
equality and pointer equality (which I'm glossing over for now),
but aside from that I see no UB.  Assuming the compiler takes
advantage of the behavior of memcmp(), it might even be able to
prove to itself that *p is valid, since p and q point to the same
location and q is definitely a valid dereferenceable pointer.

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

[toc] | [prev] | [next] | [standalone]

#122770

On 16/11/17 20:36, Keith Thompson wrote:
> Gareth Owen <gwowen@gmail.com> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>>> gcc /does/ do something wrong here - it accepts this program without
>>>> warnings, even with -Wall -Wextra.  So I do have something to complain
>>>> about here with gcc.
>>>
>>> Why do you expect a warning?  There may or may not be undefined
>>> behavior, but as far as I can tell no diagnostic is required.
>>
>> Because some people have expectations that extend beyond the C standard?
>> I appreciate that the holy standard (peace be upon it) is your sole
>> point of reference in all things, but most people quite like that GCC
>> sometimes give diagnostics for dangerous or undefined constructs, even
>> when the standard says they're not required.
>>
>> Its not unreasonable to expect one in a trivial case of UB like this.
> 
> I was replying to David Brown; please don't snip attributions.  I'm
> still curious why he expects a warning, and in particular whether he
> thinks one is required.
> 

I don't /expect/ a warning here - it is not required, and I know gcc 
does not warn about such cases.  But I would /like/ a warning here, and 
I think gcc should be capable of it.  Like most projects, the gcc folks 
must prioritise their time and effort, and can't implement every good idea.

It may be that one of gcc's sanitizer options can spot the problem - I 
haven't tested them.

gcc already has a few related issues logged - I am not the only one that 
hopes for better diagnostics (gcc's diagnostics are good, and get better 
with each version - but there is always scope for more).

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81172>
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67872>


> I don't believe this is a trivial case of UB.  I'm not even convinced
> that there's any undefined behavior.
> 
> Again, here's the code:
> 
>      #include <stdio.h>
>      #include <string.h>
> 
>      int main()
>      { int i = 1; int j = 2;
>         int * p = &i + 1; int * q = &j;
>         if( !memcmp( &p, &q, sizeof( p )))
>         { *p = 3; printf( "%d %d\n", *p, *q ); }}
> 
> p points just past the end of an object (which is treated as a
> 1-element array).  Normally dereferencing such a pointer would have
> undefined behavior, but in this case it's done only after verifying
> that that pointer is bitwise equal to a pointer to another object.
> There are some sticky issues in the relationship between bitwise
> equality and pointer equality (which I'm glossing over for now),
> but aside from that I see no UB.  Assuming the compiler takes
> advantage of the behavior of memcmp(), it might even be able to
> prove to itself that *p is valid, since p and q point to the same
> location and q is definitely a valid dereferenceable pointer.
> 

If the compiler is taking that view, and considering *p to be valid, 
then surely it must consider it to point to the same object as *q?  It 
would be unreasonable to use the equality of the pointers to show that 
*p is valid (despite the way it is derived), and then assume that it 
cannot point to the same object for optimisation purposes.

My interpretation of the standards here is that *p is undefined 
behaviour.  A compiler is of course free to consider it defined in a 
case like this - but if it does so, it should do so consistently and 
consider *q to be 3.  (Yes, I know the compiler is free to define the 
undefined behaviour in an inconsistent manner - but that would not be a 
helpful attitude for the compiler.)

It seems to me that gcc interprets "*p = 3" as undefined behaviour, 
therefore it can be ignored.

My preference would be that when the compiler sees undefined behaviour 
like this, and in particular when it uses it for optimisation like this, 
that it then issues a warning.  (I am happy to see the optimisation itself.)

[toc] | [prev] | [next] | [standalone]

#122773

On Thursday, November 16, 2017 at 3:50:28 PM UTC-6, David Brown wrote:
> My interpretation of the standards here is that *p is undefined 
> behaviour.  A compiler is of course free to consider it defined in a 
> case like this - but if it does so, it should do so consistently and 
> consider *q to be 3.  (Yes, I know the compiler is free to define the 
> undefined behaviour in an inconsistent manner - but that would not be a 
> helpful attitude for the compiler.)
> 
> It seems to me that gcc interprets "*p = 3" as undefined behaviour, 
> therefore it can be ignored.

K&R 2nd Edition states that if sizeof (T) is N, then any object of type
T will have its value encapsulated in N consecutive bytes; nothing that
I have noticed in that book even hints at the possibility that objects
whose addresses are taken might behave in a way observably contrary
to that.

Many of the more contentious parts of the Standard effectively allow
implementations to behave as though objects hold state other than what
is stored in memory.  Unfortunately, it doesn't adequately specify the
situations in which object's states may diverge from their stored bit
patterns, nor does it define means of forcing synchronization.  If the
state of p and q is fully encapsulated in the bytes occupied thereby,
then equality of those bytes must imply equivalence.  The only question
is whether p is allowed to hold state beyond what's represented in the
bytes it occupies.

[toc] | [prev] | [next] | [standalone]

#122805

On 16/11/17 23:34, supercat@casperkitty.com wrote:
> On Thursday, November 16, 2017 at 3:50:28 PM UTC-6, David Brown wrote:
>> My interpretation of the standards here is that *p is undefined 
>> behaviour.  A compiler is of course free to consider it defined in a 
>> case like this - but if it does so, it should do so consistently and 
>> consider *q to be 3.  (Yes, I know the compiler is free to define the 
>> undefined behaviour in an inconsistent manner - but that would not be a 
>> helpful attitude for the compiler.)
>>
>> It seems to me that gcc interprets "*p = 3" as undefined behaviour, 
>> therefore it can be ignored.
> 
> K&R 2nd Edition states that if sizeof (T) is N, then any object of type
> T will have its value encapsulated in N consecutive bytes; nothing that
> I have noticed in that book even hints at the possibility that objects
> whose addresses are taken might behave in a way observably contrary
> to that.

K&R does not define the C language.  It sort-of defines the language
from before there was a standard definition.

Even if it /did/, there is the as-is rule - and compilers use that.  It
is not uncommon for local data to be divided up and stored in different
ways, perhaps partly in registers and partly on the stack.  It is only
if the address of the object is taken and passed out to external code
that it becomes impractical to do anything other than store it in N
consecutive bytes.

And since we are talking about using a pointer that is set to point
/beyond/ those N bytes, the organisation of those N bytes is irrelevant
to the issue at hand.

> 
> Many of the more contentious parts of the Standard effectively allow
> implementations to behave as though objects hold state other than what
> is stored in memory.  Unfortunately, it doesn't adequately specify the
> situations in which object's states may diverge from their stored bit
> patterns, nor does it define means of forcing synchronization.  If the
> state of p and q is fully encapsulated in the bytes occupied thereby,
> then equality of those bytes must imply equivalence.  The only question
> is whether p is allowed to hold state beyond what's represented in the
> bytes it occupies.
> 

Yes, p is allowed to hold such additional state.

(In the C++ standards, there is quite a lot of information about "safely
derived" pointers that make this sort of thing more formal.  The
intention of the C++ standards writers here was, I believe, to codify,
formalise and explain the rules that have always applied in C and C++.
So for C++, the situation is very clear - p is not safely derived, and
*p is undefined behaviour.)

[toc] | [prev] | [next] | [standalone]

#122853

On Friday, November 17, 2017 at 3:44:13 AM UTC-6, David Brown wrote:
> On 16/11/17 23:34, supercat@casperkitty.com wrote:
> > K&R 2nd Edition states that if sizeof (T) is N, then any object of type
> > T will have its value encapsulated in N consecutive bytes; nothing that
> > I have noticed in that book even hints at the possibility that objects
> > whose addresses are taken might behave in a way observably contrary
> > to that.
> 
> K&R does not define the C language.  It sort-of defines the language
> from before there was a standard definition.

It describes a languages that was designed for, and is thus highly suited
for, systems programming actual machines; the language was called C by its
creator Dennis Ritchie.

Since then, the name C has also been used to refer to a few things:

1. The aforementioned language, which is described in K&R2.

2. A language whose specification looks more thorough, but only is only
   intended for programming "abstract machines", and neglects features that
   are often useful when programming real machines.

3. The union of #1 and #2.

I personally regard use of the term "C" to refer to #2, with everything else
filtered out, as a misappropriation of the term.  The name was first used
by Dennis Ritchie, and he hasn't signed over rights to anyone else, and
since language #2 is pretty well useless for those purposes to which #1 and
#3 are most suited.

Perhaps what's needed is to use different names to refer to the languages
described above.  Got any suggestions?  Note that the language described
by #3 above is not my invention--it's what quality compilers sought to
implement during the 1990s.  Throughout the 1990s the name "C" seemed like
a good one for that language, but if people want to use that name solely
for language #2 above, maybe another name is needed?

[toc] | [prev] | [next] | [standalone]

#122863

On 17/11/17 17:23, supercat@casperkitty.com wrote:
> On Friday, November 17, 2017 at 3:44:13 AM UTC-6, David Brown wrote:
>> On 16/11/17 23:34, supercat@casperkitty.com wrote:
>>> K&R 2nd Edition states that if sizeof (T) is N, then any object of type
>>> T will have its value encapsulated in N consecutive bytes; nothing that
>>> I have noticed in that book even hints at the possibility that objects
>>> whose addresses are taken might behave in a way observably contrary
>>> to that.
>>
>> K&R does not define the C language.  It sort-of defines the language
>> from before there was a standard definition.
> 
> It describes a languages that was designed for, and is thus highly suited
> for, systems programming actual machines; the language was called C by its
> creator Dennis Ritchie.

"Describes" is not "defines".  In the days of the K&R book, there were
several inconsistent C implementations.  The book was a rough standard,
and compilers followed it approximately, but it was not until ANSI C89
that the language was defined and standardised.

> 
> Since then, the name C has also been used to refer to a few things:
> 
> 1. The aforementioned language, which is described in K&R2.
> 
> 2. A language whose specification looks more thorough, but only is only
>    intended for programming "abstract machines", and neglects features that
>    are often useful when programming real machines.
> 
> 3. The union of #1 and #2.

You forgot:

4. An imagined language that acts dumbly according to every piece of
source code with a memory and execution model matching the cpu (it does
not do this, but some people think it does).

5. An imagined language that used to have unwritten rules about how it
should behave, and is defined now by a mixture of written standards and
ideas about what the standards authors really meant based on the
imagined unwritten rules.

6. A language whose main definition is from standards (currently C11),
augmented by the implementation-specific definitions required by the
standards, and additional extensions, enhancements and definitions
provided by particular implementations.

> 
> I personally regard use of the term "C" to refer to #2

The use of quotation marks here is an extraordinarily petty and
self-righteous condemnation of the work done by the C standards
committee and C compiler developers everywhere.  The paper you like to
refer to, and are copying from here, made some interesting points - but
it's pathetic distinction between C and "C", and optimisations and
"optimisations", makes it sensationalist trash.  You would do well not
to copy it.

> with everything else
> filtered out, as a misappropriation of the term.  The name was first used
> by Dennis Ritchie, and he hasn't signed over rights to anyone else, and
> since language #2 is pretty well useless for those purposes to which #1 and
> #3 are most suited.

The name is not copyrighted or trademarked, to my knowledge.

For some people, C is somewhat abstract - they aim to write maximally
portable code.  But most people use C as #6 above - a language which is
very well suited to the original purposes #1 and which lets people write
systems programming code, low-level libraries, OS's, as well as
applications - both portable code and implementation specific code.

If you exchange "C11 standards" for "K&R book", then #6 is how C was
when that book was written.  It has /never/ been #5 - the definition you
actually follow (not #3, as you claim - nor did "quality compilers of
the 1990's" go for #3).

> 
> Perhaps what's needed is to use different names to refer to the languages
> described above.  Got any suggestions?  Note that the language described
> by #3 above is not my invention--it's what quality compilers sought to
> implement during the 1990s.  Throughout the 1990s the name "C" seemed like
> a good one for that language, but if people want to use that name solely
> for language #2 above, maybe another name is needed?
> 

I like C.  And I will use quotation marks "C" according to taste and
grammar - not according to childish whims of someone with a bee in his
bonnet about his problems using modern compilers.  We only need one
name, because there is only one C language.

[toc] | [prev] | [next] | [standalone]

#122899

On Friday, November 17, 2017 at 12:13:28 PM UTC-6, David Brown wrote:
> On 17/11/17 17:23, supercat@casperkitty.com wrote:
> > On Friday, November 17, 2017 at 3:44:13 AM UTC-6, David Brown wrote:
> >> On 16/11/17 23:34, supercat@casperkitty.com wrote:
> >>> K&R 2nd Edition states that if sizeof (T) is N, then any object of type
> >>> T will have its value encapsulated in N consecutive bytes; nothing that
> >>> I have noticed in that book even hints at the possibility that objects
> >>> whose addresses are taken might behave in a way observably contrary
> >>> to that.
> >>
> >> K&R does not define the C language.  It sort-of defines the language
> >> from before there was a standard definition.
> > 
> > It describes a languages that was designed for, and is thus highly suited
> > for, systems programming actual machines; the language was called C by its
> > creator Dennis Ritchie.
> 
> "Describes" is not "defines".  In the days of the K&R book, there were
> several inconsistent C implementations.  The book was a rough standard,
> and compilers followed it approximately, but it was not until ANSI C89
> that the language was defined and standardised.

Whether or not any official standards body recognized the language, most
implementations of C in the 1980s which targeted microprocessors were
very consistent in how they mapped core aspects of the language to a
target platform.  One would not need to read the documentation for a Z80
C compiler, for example, to know that unless it was configured in some
unusual fashion, the code:

    *(int*)0x1234 = 0x5678;

would cause values 0x34 to be written to address 0x5678 and 0x12 to be
written to address 0x5679.

> The use of quotation marks here is an extraordinarily petty and
> self-righteous condemnation of the work done by the C standards
> committee and C compiler developers everywhere.  The paper you like to
> refer to, and are copying from here, made some interesting points - but
> it's pathetic distinction between C and "C", and optimisations and
> "optimisations", makes it sensationalist trash.  You would do well not
> to copy it.

What names would you prefer to distinguish the language defined by Standard
for freestanding implementations, versus a language which would be formed
by adding a couple additional guarantees:

   Every object of size N which is of static duration or has its address
   taken must behave as though its state is encapsulated in N bytes starting
   at address N, and scalar types must use the same representation as defined
   by the underlying platform.

   In cases where the Standard does not define the behavior of a numeric or
   pointer arithmetic operation or comparison, but a platform does, the
   implementation will behave according to the platform's defined behavior.

Certainly there are many programs for hosted implementations which would
not benefit from such guarantees, and even programs for freestanding
implementations could usually get by with weaker ones.  On the other hand,
the latter language would be sufficient to accomplish a very wide range of
useful tasks on many platforms without reliance upon any compiler-specific
features beyond those two.

Given that the latter language can do vastly more things than the one defined
by the Standard, I would think it deserves a name.  What name would you
recommend?

I would certainly agree that the language described above could be improved
by allowing programmers to waive aspects of those guarantees that they don't
need.  On the other hand, I would suggest that any language which wants to
use the same name as the language that became popular in the 1980s should
be capable of doing everything that could be done in that language.

Perhaps what's needed is a notation C[platform] to denote the language C
augmented by the guarantees associated with a specified platform, in which
case the freestanding language defined by Standard would be C[abstract
machine unrelated to any practical hardware].

[toc] | [prev] | [next] | [standalone]

#122907

On Fri, 17 Nov 2017 16:45:55 -0800 (PST)
supercat@casperkitty.com wrote:
> On Friday, November 17, 2017 at 12:13:28 PM UTC-6, David Brown wrote:
> > On 17/11/17 17:23, supercat@casperkitty.com wrote:
> > > On Friday, November 17, 2017 at 3:44:13 AM UTC-6, David Brown wrote:
> > >> On 16/11/17 23:34, supercat@casperkitty.com wrote:
> > >>> K&R 2nd Edition states that if sizeof (T) is N, then any object of type
> > >>> T will have its value encapsulated in N consecutive bytes; nothing that
> > >>> I have noticed in that book even hints at the possibility that objects
> > >>> whose addresses are taken might behave in a way observably contrary
> > >>> to that.
> > >>
> > >> K&R does not define the C language.  It sort-of defines the language
> > >> from before there was a standard definition.
> > > 
> > > It describes a languages that was designed for, and is thus highly suited
> > > for, systems programming actual machines; the language was called C by its
> > > creator Dennis Ritchie.
> > 
> > "Describes" is not "defines".  In the days of the K&R book, there were
> > several inconsistent C implementations.  The book was a rough standard,
> > and compilers followed it approximately, but it was not until ANSI C89
> > that the language was defined and standardised.
> 
> Whether or not any official standards body recognized the language, most
> implementations of C in the 1980s which targeted microprocessors were
> very consistent in how they mapped core aspects of the language to a
> target platform.  One would not need to read the documentation for a Z80
> C compiler, for example, to know that unless it was configured in some
> unusual fashion, the code:
> 
>     *(int*)0x1234 = 0x5678;
> 
> would cause values 0x34 to be written to address 0x5678 and 0x12 to be
> written to address 0x5679.

I think you have address and value reversed.

Given the caveat "unless it was configured in some unusual fashion" ,
wouldn't one need to read the documentation after all ?

Address 0x1234 may be ROM in which case nothing will be written. So at best
you're saying that if the C source code has
    *(int*)0x1234 = 0x5678;

then you want the compiler to emit assembly instruction(s) to (attempt to)
write the value 0x5678 to the appropriate memory locations based on
endianess. Obviously this isn't portable for reasons having to do with the
architecture and not with the C standard. Is there any architecture where
such a thing would be useful and the C compilers don't support it ? Even if
they don't , nothing in the standard prevents them from supporting it.

For a more realistic example , I'm aware that C compilers for MSDOS had
extensions for near and far pointers. If some C source used such extensions
would it compile on say a Unix system ?

Overall I'm not sure that the consistency you claim actually existed back
then and even if it did that it made it easier to write useful code (as
opposed to contrived examples).

> > The use of quotation marks here is an extraordinarily petty and
> > self-righteous condemnation of the work done by the C standards
> > committee and C compiler developers everywhere.  The paper you like to
> > refer to, and are copying from here, made some interesting points - but
> > it's pathetic distinction between C and "C", and optimisations and
> > "optimisations", makes it sensationalist trash.  You would do well not
> > to copy it.
> 
> What names would you prefer to distinguish the language defined by Standard
> for freestanding implementations, versus a language which would be formed
> by adding a couple additional guarantees:
> 
>    Every object of size N which is of static duration or has its address
>    taken must behave as though its state is encapsulated in N bytes starting
>    at address N, and scalar types must use the same representation as defined
>    by the underlying platform.

"address N" : did you mean to use a different letter ?

"state is encapsulated in N bytes" : this is meaningless since the standard
does not give any definition for an object state. So to have something
meaningful you need to provide such a definition and describe how the state
of an object interacts with other parts of the language.

"scalar types must use the same representation as defined by the underlying
platform" : if I interpret this correctly , a conforming implementation would
be forbidden for adding metainformation to things like pointers. Such
metainformation might be the size of the object they point to. I think this
would be an unfortunate restriction ; so called fat pointers can reduce
errors at the cost of some speed. A conforming implementation should not be
precluded from offering such a trade off. Also , what would your restriction
mean for an interpreted C ? (I'm not actually sure whether an interpreted C
can count as freestanding)

>    In cases where the Standard does not define the behavior of a numeric or
>    pointer arithmetic operation or comparison, but a platform does, the
>    implementation will behave according to the platform's defined behavior.

Unless the platform's definitions use C terms , I don't see how this means
anything. A microprocessor documentation will talk about things like registers
and addressing modes. It is up to a C implementation to define a correspondence
between those and C concepts like pointers. So what would it mean for a C
implementation to follow the platform's definitions ?

> Certainly there are many programs for hosted implementations which would
> not benefit from such guarantees, and even programs for freestanding
> implementations could usually get by with weaker ones.  On the other hand,
> the latter language would be sufficient to accomplish a very wide range of
> useful tasks on many platforms without reliance upon any compiler-specific
> features beyond those two.

Would it be able to do so portably ? If not then what's the improvement over
relying on compiler specific extensions ?

> Given that the latter language can do vastly more things than the one defined
> by the Standard, I would think it deserves a name.  What name would you
> recommend?

To the extent that I can guess your intentions , I would propose
    PAC = portable assembly C

.I think your complaint is that C was more of a portable assembly in the
1980s than it is now but I'm not convinced that this is correct and even if
it is , that it is because of the standard and not because the processors have
become more elaborate or because compilers have become better at doing
optimisations.

> I would certainly agree that the language described above could be improved
> by allowing programmers to waive aspects of those guarantees that they don't
> need.

If your suggestions would mean fewer opportunities for optimisations then I
would say that it is essential that the programmer has the ability to waive
the additional constraints.

> On the other hand, I would suggest that any language which wants to
> use the same name as the language that became popular in the 1980s should
> be capable of doing everything that could be done in that language.

I'm pretty sure it can and a lot more.

> Perhaps what's needed is a notation C[platform] to denote the language C
> augmented by the guarantees associated with a specified platform, in which
> case the freestanding language defined by Standard would be C[abstract
> machine unrelated to any practical hardware].

Who would define those C[platform] guarantees ? Surely not the C standard
committee because it would be impossible to do so. If you mean some external
group then there's nothing which prevents a group or individual to define an
extended C which in some way works better on some specific architecture. If
you have any specific ideas go ahead and write a document and put in online.
But otherwise many of your suggestions (not just in this post) are too vague.

-- 
Who watches the watchers ?
Who bakes the bakers ?
Who builds the builders ?
Who programs the programmers ?

[toc] | [prev] | [next] | [standalone]

#122768

On 16/11/17 17:55, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>>>> On 16/11/17 11:00, Stefan Ram wrote:
>>>>>     I did not invent this program, I just read it in an article
>>>>>     and then typed it in from my memory:
>>>>>
>>>>>     main.c
>>>>>
>>>>> #include <stdio.h>
>>>>> #include <string.h>
>>>>>
>>>>> int main()
>>>>> { int i = 1; int j = 2;
>>>>>     int * p = &i + 1; int * q = &j;
>>>>>     if( !memcmp( &p, &q, sizeof( p )))
>>>>>     { *p = 3; printf( "%d %d\n", *p, *q ); }}
>>>>>
>>>>>     transcript
>>>>>
>>>>> 3 2
> [...]
> 
>> gcc /does/ do something wrong here - it accepts this program without
>> warnings, even with -Wall -Wextra.  So I do have something to complain
>> about here with gcc.
> 
> Why do you expect a warning?  There may or may not be undefined
> behavior, but as far as I can tell no diagnostic is required.

No diagnostic is /required/ - I believe you are correct there.  But a 
warning would be helpful.  Usually when a program has undefined 
behaviour, you have a mistake somewhere - it is good if a compiler tells 
the programmer about it.  (Issuing a diagnostic is certainly a 
permissible behaviour for the undefined behaviour.)

> 
> For example,
>      int *p = &i = 1;
> is valid; the object i can be treated as a single element array, and p
> points just past the end of it.  Normally dereferencing p would have
> undefined behavior (which a compiler could detect only if it does data
> flow analysis).

gcc does do such data flow analysis (when optimisation is enabled), so 
it should be capable of giving a warning when it knows the behaviour is 
undefined.  It has a warning option "-Warray-bounds" that can detect 
some static out-of-bounds array accesses, but it is not strong enough to 
detect this one.

But pclint (a C linter program) is able to detect this fault, and gives:

Warning 415:  Likely access of out-of-bounds pointer (1 beyond end of 
data) by operator 'unary *'

> 
> I'll have more to say in a followup to the original post.
> 

[toc] | [prev] | [next] | [standalone]

#122777

David Brown <david.brown@hesbynett.no> writes:

> On 16/11/17 17:55, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>>>> On 16/11/17 11:00, Stefan Ram wrote:
>>>>>>     I did not invent this program, I just read it in an article
>>>>>>     and then typed it in from my memory:
>>>>>>
>>>>>>     main.c
>>>>>>
>>>>>> #include <stdio.h>
>>>>>> #include <string.h>
>>>>>>
>>>>>> int main()
>>>>>> { int i = 1; int j = 2;
>>>>>>     int * p = &i + 1; int * q = &j;
>>>>>>     if( !memcmp( &p, &q, sizeof( p )))
>>>>>>     { *p = 3; printf( "%d %d\n", *p, *q ); }}
>>>>>>
>>>>>>     transcript
>>>>>>
>>>>>> 3 2
>> [...]
>>
>>> gcc /does/ do something wrong here - it accepts this program without
>>> warnings, even with -Wall -Wextra.  So I do have something to complain
>>> about here with gcc.
>>
>> Why do you expect a warning?  There may or may not be undefined
>> behavior, but as far as I can tell no diagnostic is required.
>
> No diagnostic is /required/ - I believe you are correct there.  But a
> warning would be helpful.  Usually when a program has undefined
> behaviour, you have a mistake somewhere - it is good if a compiler
> tells the programmer about it.  (Issuing a diagnostic is certainly a
> permissible behaviour for the undefined behaviour.)

The trouble is that the compiler is probably not detecting undefined
behaviour and ignoring the undefined code (that's how you described the
situation up thread).  In cases like that it would indeed be great if
compilers would say "I ignored some code, you should check it".

But that's probably not what's happening.  The compiler ignores the
write though p even when it's defined (say by making p = &i) because it
can see that only *p is needed later and *that* optimisation would throw
up all sorts of annoying messages were it to be reported in every case.
The other fact, that nothing in the code aliases j is also very common
in perfectly legal code and would throw up far too many warnings were it
to be reported.

These two are enough to explain the fact that gcc determines, at compile
time, that 3 and 2 should be printed.  To report the undefined behaviour
in this case, gcc would have to have code specifically design to look
for it.

There may be cases where gcc *is* simply ignoring undefined code and not
reporting that fact, but it need not be the case here.

(I admit there is more guessing on my part here, but it's not entirely
uninformed guessing.)

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#122787

On Thursday, November 16, 2017 at 5:11:48 PM UTC-6, Ben Bacarisse wrote:
> But that's probably not what's happening.  The compiler ignores the
> write though p even when it's defined (say by making p = &i) because it
> can see that only *p is needed later and *that* optimisation would throw
> up all sorts of annoying messages were it to be reported in every case.
> The other fact, that nothing in the code aliases j is also very common
> in perfectly legal code and would throw up far too many warnings were it
> to be reported.

The authors of the Standard did not want to require that implementations
keep objects' representations in memory precisely synchronized with their
values in places where there was no evidence that doing otherwise would
observably affect behavior.  Unfortunately, rather than simply saying that
and then describing some kinds of evidence implementations must recognize
(and noting that implementations intended to be suitable for e.g. systems
programming may need to recognize more forms than those intended for e.g.
numerical analysis) the authors of the Standard threw together some vague
ad hoc rules which allow compilers to attach state to objects beyond what
is represented in the bits thereof, but never considered how those rules
would interact with other parts of the Standard.

If useful optimizations would be facilitated by weakening the definition
of pointer equality such that a comparison between a pointer to one object
and a pointer "just-past" another object would yield 0 or 1 in Unspecified
fashion, the proper way to facilitate that would be to define a directive
by which code that didn't need a compiler to guarantee pointer-equality
behavior could waive it.  If behavioral waivers were of a form like:

    __STDC_WAIVE_BEHAVIOR(PTR_EQUALITY_EQUIVALENCE)

then an implementation which doesn't want to process behavioral waivers
could be compatible with programs using them simply by predefining

    #define __STDC_WAIVE_BEHAVIOR(x)

while those that process some waivers could simply ignore any others they
don't understand.

Maybe waiving the relationship between pointer and equivalence would allow
enough useful optimizations to justify the effort of programmers using such
a directive and maybe it wouldn't, but having compilers refrain from making
optimizations in cases where they'd be useful seems a lot less harmful than
revoking behavioral guarantees that some programs rely upon.

[toc] | [prev] | [next] | [standalone]

#122806

On 17/11/17 00:11, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 16/11/17 17:55, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>>>> On 16/11/17 11:00, Stefan Ram wrote:
>>>>>>>     I did not invent this program, I just read it in an article
>>>>>>>     and then typed it in from my memory:
>>>>>>>
>>>>>>>     main.c
>>>>>>>
>>>>>>> #include <stdio.h>
>>>>>>> #include <string.h>
>>>>>>>
>>>>>>> int main()
>>>>>>> { int i = 1; int j = 2;
>>>>>>>     int * p = &i + 1; int * q = &j;
>>>>>>>     if( !memcmp( &p, &q, sizeof( p )))
>>>>>>>     { *p = 3; printf( "%d %d\n", *p, *q ); }}
>>>>>>>
>>>>>>>     transcript
>>>>>>>
>>>>>>> 3 2
>>> [...]
>>>
>>>> gcc /does/ do something wrong here - it accepts this program without
>>>> warnings, even with -Wall -Wextra.  So I do have something to complain
>>>> about here with gcc.
>>>
>>> Why do you expect a warning?  There may or may not be undefined
>>> behavior, but as far as I can tell no diagnostic is required.
>>
>> No diagnostic is /required/ - I believe you are correct there.  But a
>> warning would be helpful.  Usually when a program has undefined
>> behaviour, you have a mistake somewhere - it is good if a compiler
>> tells the programmer about it.  (Issuing a diagnostic is certainly a
>> permissible behaviour for the undefined behaviour.)
> 
> The trouble is that the compiler is probably not detecting undefined
> behaviour and ignoring the undefined code (that's how you described the
> situation up thread).  In cases like that it would indeed be great if
> compilers would say "I ignored some code, you should check it".
> 
> But that's probably not what's happening.  The compiler ignores the
> write though p even when it's defined (say by making p = &i) because it
> can see that only *p is needed later and *that* optimisation would throw
> up all sorts of annoying messages were it to be reported in every case.

I think you are correct.  Sometimes warnings that might have been nice
to have in gcc, don't occur because the order of passes and
optimisations means that the errant code is eliminated before it is
seen.  (And I agree that we don't want messages about such eliminated
stores.)

> The other fact, that nothing in the code aliases j is also very common
> in perfectly legal code and would throw up far too many warnings were it
> to be reported.
> 
> These two are enough to explain the fact that gcc determines, at compile
> time, that 3 and 2 should be printed.  To report the undefined behaviour
> in this case, gcc would have to have code specifically design to look
> for it.
> 
> There may be cases where gcc *is* simply ignoring undefined code and not
> reporting that fact, but it need not be the case here.

There are such cases, yes.  But I agree it sounds like it is not what is
happening here.

> 
> (I admit there is more guessing on my part here, but it's not entirely
> uninformed guessing.)
> 

Your explanation makes sense.

I would still like a warning about the undefined behaviour in my code
here, of course - but I can see how it would be difficult for gcc to
give it.

[toc] | [prev] | [next] | [standalone]

#122750

David Brown <david.brown@hesbynett.no> writes:

>>> Garbage in, garbage out.
>> 
>> You seem to be so in love with gcc that it apparently can do no wrong.
>> 
>
> It is the way C is defined.  Should I complain about a C compiler that
> compiles C code according to the rules of C?

Please remember, you are talking to a moron.

[toc] | [prev] | [next] | [standalone]

#122751

On Thursday, November 16, 2017 at 2:21:06 PM UTC-5, gwowen wrote:
> Please remember, you are talking to a moron.

Man will be judged for every idle word he speaks, gwowen.  How much
judgment will there be for name calling?

    https://www.biblegateway.com/passage/?search=Matthew+12%3A36&version=KJV

Is that really the world you want to live in?  That world of divisions
made by your own doing?  What barrier is there between you and another
person except for those which you personally erect yourself?  Insomuch
as it depends upon you, that is the ONLY barrier that exists.

This really is your life, gwowen.  You owe the people around you better
than you are giving to them.  You owe yourself, your family, your kids,
co-workers, classmates, whatever.  You owe better than such behavior.

If there's someone around you who needs help because they're not yet
where they should be, then help them.  Don't call them names.  Lift
them up and in so doing gain a friend, and demonstrate to others how
it should be done.

--
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#122772

In article <871skyav3a.fsf@gmail.com>, Gareth Owen  <gwowen@gmail.com> wrote:
>David Brown <david.brown@hesbynett.no> writes:
>
>>>> Garbage in, garbage out.
>>> 
>>> You seem to be so in love with gcc that it apparently can do no wrong.
>>> 
>>
>> It is the way C is defined.  Should I complain about a C compiler that
>> compiles C code according to the rules of C?
>
>Please remember, you are talking to a moron.

Indeed.

http://www.youtube.com/watch?v=1WlAZ7SLuUw

People do need to always keep this in mind, when they choose to engage with
Mr. Hodgin.

-- 
BigBusiness types (aka, Republicans/Conservatives/Independents/Liberatarians/whatevers)
don't hate big government. They *love* big government as a means for them to get
rich, sucking off the public teat. What they don't like is *democracy* - you know,
like people actually having the right to vote and stuff like that.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web