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

Groups > comp.lang.c++ > #44630 > unrolled thread

This will work or not?

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

Contents

  This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-08-31 14:59 +0200
    Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 15:20 +0200
      Re: This will work or not? mark <mark@invalid.invalid> - 2016-08-31 16:05 +0200
        Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 16:19 +0200
      Re: This will work or not? scott@slp53.sl.home (Scott Lurndal) - 2016-08-31 14:20 +0000
      Re: This will work or not? Bo Persson <bop@gmb.dk> - 2016-08-31 18:53 +0200
        Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 09:03 -0700
          Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 22:45 +0200
            Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 18:08 -0700
              Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 09:24 +0200
                Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 06:31 -0700
                  Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-04 20:19 +0200
    Re: This will work or not? Manfred <noname@invalid.add> - 2016-08-31 15:45 +0200
      Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-08-31 15:59 +0200
      Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 16:22 +0200
        Re: This will work or not? Manfred <noname@invalid.add> - 2016-08-31 17:06 +0200
          Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-08-31 19:29 +0200
            Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-08-31 21:52 +0100
              Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 09:07 +0200
                Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-01 12:30 +0100
              Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 09:01 -0700
                Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-01 18:16 +0100
                  Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 18:37 -0700
                    Re: This will work or not? Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2016-09-02 10:42 +0100
                      Re: This will work or not? Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 06:59 -0700
            Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-31 23:17 -0400
              Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 09:35 +0200
                Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 15:34 -0400
                  Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-01 13:50 -0700
                    Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 21:01 -0400
                      Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-01 19:02 -0700
                        Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 22:17 -0400
                          Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 08:19 -0700
                            Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:39 -0400
                              Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 12:26 -0700
                                Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:38 -0400
                                  Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 13:51 -0700
                                    Re: This will work or not? me <crisdunbar@gmail.com> - 2016-09-02 14:16 -0700
                                    Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 19:58 -0400
                                Re: This will work or not? Paavo Helde <myfirstname@osa.pri.ee> - 2016-09-02 23:56 +0300
                                  Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-03 17:58 +0200
                        Re: This will work or not? Manfred <noname@invalid.add> - 2016-09-02 11:41 +0200
                          Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 12:27 +0200
                            Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-02 12:37 +0100
                              Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:39 +0200
                                Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-02 17:40 +0200
                                Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-02 16:54 +0100
                                  Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 20:22 +0200
                            Re: This will work or not? Richard Damon <Richard@Damon-Family.org> - 2016-09-02 08:04 -0400
                              Re: This will work or not? BartC <bc@freeuk.com> - 2016-09-02 13:51 +0100
                                Re: This will work or not? Richard Damon <Richard@Damon-Family.org> - 2016-09-02 21:48 -0400
                            Re: This will work or not? Manfred <noname@invalid.add> - 2016-09-02 15:17 +0200
                              Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:46 +0200
                  Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-01 23:14 +0200
                    Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-01 21:02 -0400
                      Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 09:35 +0200
                        Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 08:50 -0400
                          Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 17:59 +0200
                            Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 12:49 -0400
                              Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-02 20:36 +0200
                                Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-02 16:32 -0400
                                  Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-03 18:08 +0200
                                    Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 18:25 -0400
                                      Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-03 23:51 +0100
                                        Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 21:48 -0400
                                          Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 03:48 +0100
                                            Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 23:05 -0400
                                              Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 05:02 +0100
                                                Re: This will work or not? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-04 10:57 +0100
                                                  Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 09:40 -0400
                                                    Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 16:39 +0100
                                                      Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 12:46 -0400
                                                        Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 17:51 +0100
                                                          Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:07 -0400
                                                            Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 18:37 +0100
                                                              Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:16 -0400
                                                                Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 22:23 +0100
                                                                  Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 18:54 -0400
                                                        Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 09:58 -0700
                                                          Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:08 -0400
                                                            Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 10:21 -0700
                                                              Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:18 -0400
                                                                Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 22:24 +0100
                                                                  Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 18:56 -0400
                                                                    Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 00:27 +0100
                                                                      Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:53 -0400
                                                                        Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 18:18 +0100
                                                                          Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 15:27 -0400
                                                                            Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 20:32 +0100
                                                                              Re: This will work or not? woodbrian77@gmail.com - 2016-09-05 14:07 -0700
                                                                              Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 18:15 -0400
                                                                            Re: This will work or not? Ike Naar <ike@iceland.freeshell.org> - 2016-09-05 20:12 +0000
                                                                              Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-05 22:05 +0100
                                                                              Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-05 18:16 -0400
                                                                                Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-06 08:47 +0200
                                                                                  Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-06 09:12 -0400
                                                                                    Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-06 16:31 +0200
                                                                                      Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-06 11:20 -0400
                                                                  Re: This will work or not? bighe.trole@gmail.com - 2016-09-04 18:55 -0700
                                                                    Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:55 -0400
                                                                Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-04 17:17 -0700
                                                                  Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 22:57 -0400
                                                                    Re: This will work or not? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-09-05 11:20 -0700
                                                      Re: This will work or not? Luuk <luuk@invalid.lan> - 2016-09-04 18:54 +0200
                                                        Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 17:59 +0100
                                                        Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 13:08 -0400
                                                        Re: This will work or not? David Brown <david.brown@hesbynett.no> - 2016-09-04 20:25 +0200
                                                          Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 17:20 -0400
                                              Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-04 02:36 -0700
                                                Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-04 09:41 -0400
                                        Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 21:49 -0400
                                          Re: This will work or not? Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2016-09-04 03:49 +0100
                                            Re: This will work or not? Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-03 23:06 -0400
                                              Re: This will work or not? woodbrian77@gmail.com - 2016-09-03 21:16 -0700
    Re: This will work or not? Vir Campestris <vir.campestris@invalid.invalid> - 2016-08-31 21:08 +0100
    Re: This will work or not? "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2016-09-01 02:28 +0200
      Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-01 01:28 -0700
      Re: This will work or not? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-02 12:06 -0700
    Re: This will work or not? Öö Tiib <ootiib@hot.ee> - 2016-09-05 02:21 -0700
      Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-05 13:38 +0200
    Re: This will work or not? Juha Nieminen <nospam@thanks.invalid> - 2016-09-05 11:34 +0000
      Re: This will work or not? Melzzzzz <mel@zzzzz.com> - 2016-09-05 13:36 +0200
        Re: This will work or not? Vir Campestris <vir.campestris@invalid.invalid> - 2016-09-05 21:25 +0100

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

#44683

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:

> On Wed, 31 Aug 2016 19:29:57 +0200
> David Brown <david.brown@hesbynett.no> wrote:
> [snip]
>> Apparently, you are not allowed to access the different parts of the
>> union as I had thought.  My knowledge of such details in C++ is a
>> good deal less than my knowledge of C, and my knowledge of C has
>> holes too!
>
> It has undefined behaviour in C89, and C99 as originally printed.  It
> has defined behaviour in C99 with Technical Corrigendum 3 applied and in
> C11, except that if there are padding bytes they can have a trap
> representation (section 6.2.6.1/6 and /7 of C11 read with footnote 95 of
> section 6.5.2.3/3 if you want the reference).  [...]

I believe you are misreading or misremembering some of the various
C standards here.  The behavior in C89 was implementation-defined,
not undefined.  For section 6.2.6.1 p6 and p7, there is no
difference in the substance between C99 and C99-post-TC3, as it
relates to the example (for reference here is that code again):

    struct Problem {
        union {
            struct {
                uint32_t a;
                uint32_t b;
                uint64_t c;
                uint32_t d;
            }
            uint32_t as_array[5];
        }
        // [.. original had a C++ member function ..]
    }

It is true that if there are padding bytes between the members of
the inner struct those bytes may have unspecified values, but that
cannot cause undefined behavior for an access through 'as_array',
because the type uint32_t cannot have any trap representations.

As far as footnote 95 goes, footnotes are informative, not
normative;  adding this footnote makes no difference to what is
defined behavior (although it may make that more obvious).
Moreover the notes of discussion regarding the footnote make it
clear that the point of adding it was just to be sure readers
would understand the semantics guaranteed under the original C99
standard (and effectively what was meant all along in C89, which
was phrased not as well as it might have been).  The footnote
doesn't change anything;  it just makes the existing semantics
more evident.

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

#44688

On Thu, 01 Sep 2016 09:01:10 -0700
Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> 
> > On Wed, 31 Aug 2016 19:29:57 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> > [snip]  
> >> Apparently, you are not allowed to access the different parts of
> >> the union as I had thought.  My knowledge of such details in C++
> >> is a good deal less than my knowledge of C, and my knowledge of C
> >> has holes too!  
> >
> > It has undefined behaviour in C89, and C99 as originally printed.
> > It has defined behaviour in C99 with Technical Corrigendum 3
> > applied and in C11, except that if there are padding bytes they can
> > have a trap representation (section 6.2.6.1/6 and /7 of C11 read
> > with footnote 95 of section 6.5.2.3/3 if you want the reference).
> > [...]  
> 
> I believe you are misreading or misremembering some of the various
> C standards here.  The behavior in C89 was implementation-defined,
> not undefined.  For section 6.2.6.1 p6 and p7, there is no
> difference in the substance between C99 and C99-post-TC3, as it
> relates to the example (for reference here is that code again):

On actually looking up §6.3.2.3 of C89/90 I concede you are right: it
is implementation-defined and not undefined.  So much for memory.  I
think you are also probably right about C99, given that footnotes are
not normative, although C99/11 gets awfully close to putting apparently
normative statements in footnotes.

>     struct Problem {
>         union {
>             struct {
>                 uint32_t a;
>                 uint32_t b;
>                 uint64_t c;
>                 uint32_t d;
>             }
>             uint32_t as_array[5];
>         }
>         // [.. original had a C++ member function ..]
>     }
> 
> It is true that if there are padding bytes between the members of
> the inner struct those bytes may have unspecified values, but that
> cannot cause undefined behavior for an access through 'as_array',
> because the type uint32_t cannot have any trap representations.

I think you are wrong about that.  §6.2.6.1/5, /6 and /7 read together
seem to me to be clear enough that if you type pun through a union where
the last value stored has padding, the bytes representing the padding
have an unspecified value which may be a trap representation if
actually read.  You cannot get a trap representation from arithmetic
operations on valid values of unsigned integers, but that seems to me
to be a different matter.  Integer values may have padding bits or
parity bits.

Chris

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

#44720

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:

> On Thu, 01 Sep 2016 09:01:10 -0700
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
>>
>>> On Wed, 31 Aug 2016 19:29:57 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>> [snip]
>>>> Apparently, you are not allowed to access the different parts of
>>>> the union as I had thought.  My knowledge of such details in C++
>>>> is a good deal less than my knowledge of C, and my knowledge of C
>>>> has holes too!
>>>
>>> It has undefined behaviour in C89, and C99 as originally printed.
>>> It has defined behaviour in C99 with Technical Corrigendum 3
>>> applied and in C11, except that if there are padding bytes they can
>>> have a trap representation (section 6.2.6.1/6 and /7 of C11 read
>>> with footnote 95 of section 6.5.2.3/3 if you want the reference).
>>> [...]
>>
>> I believe you are misreading or misremembering some of the various
>> C standards here.  The behavior in C89 was implementation-defined,
>> not undefined.  For section 6.2.6.1 p6 and p7, there is no
>> difference in the substance between C99 and C99-post-TC3, as it
>> relates to the example (for reference here is that code again):
>
> On actually looking up section 6.3.2.3 of C89/90 I concede you are
> right:  it is implementation-defined and not undefined.  So much
> for memory.  I think you are also probably right about C99, given
> that footnotes are not normative, although C99/11 gets awfully
> close to putting apparently normative statements in footnotes.

Yes I think that does hold true for some footnotes.  In the case
of this particular footnote, I have carefully gone through what
look like the relevant normative sections, and concluded that
there is in fact normative support for what the footnote says.
(I hasten to add the conclusion is nowhere near as obvious as I
would like.)  So I think we are in agreement on this one.

>>     struct Problem {
>>         union {
>>             struct {
>>                 uint32_t a;
>>                 uint32_t b;
>>                 uint64_t c;
>>                 uint32_t d;
>>             }
>>             uint32_t as_array[5];
>>         }
>>         // [.. original had a C++ member function ..]
>>     }
>>
>> It is true that if there are padding bytes between the members of
>> the inner struct those bytes may have unspecified values, but that
>> cannot cause undefined behavior for an access through 'as_array',
>> because the type uint32_t cannot have any trap representations.
>
> I think you are wrong about that.  Sections 6.2.6.1/5, /6 and /7
> read together seem to me to be clear enough that if you type pun
> through a union where the last value stored has padding, the bytes
> representing the padding have an unspecified value

I agree with you on that, in particular for the case where the
other member in question being a struct, which is the case here.

> which may be a
> trap representation if actually read.

Again I agree, although it depends on the type used to do the
reading.

> You cannot get a trap
> representation from arithmetic operations on valid values of
> unsigned integers, but that seems to me to be a different matter.
> Integer values may have padding bits or parity bits.

That is true for integer types generally, but the fixed-width
types like uint32_t have additional guarantees that preclude the
possibility of padding bits or trap representations.  You might
want to look that up in the section for <stdint.h>.  The lack of
trap representations for uint32_t forms the crux of my argument.
(Probably I should have mentioned the more stringent guarantees
for these fixed-width types before, but 20-20 hindsight and all
that...)

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

#44728

On Thu, 01 Sep 2016 18:37:47 -0700
Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:
> > You cannot get a trap
> > representation from arithmetic operations on valid values of
> > unsigned integers, but that seems to me to be a different matter.
> > Integer values may have padding bits or parity bits.  
> 
> That is true for integer types generally, but the fixed-width
> types like uint32_t have additional guarantees that preclude the
> possibility of padding bits or trap representations.  You might
> want to look that up in the section for <stdint.h>.  The lack of
> trap representations for uint32_t forms the crux of my argument.
> (Probably I should have mentioned the more stringent guarantees
> for these fixed-width types before, but 20-20 hindsight and all
> that...)

OK that's good to know.  The thesis in my original post on this was
that if you compile the type-punning code as C99 or C11 and link to it
in your C++ code it would work, because no architectures in fact running
C++ have trap representations on integers in C.  You are, like Judge
Dredd, saying that it will work because it _is_ the law, for fixed size
unsigned integers at least.

Apropos of which, and moving on from indeterminate values arising from
padding to indeterminate values arising from uninitialized built-in
types, C appears to do this much better than the proposal in what is
now §8.6/12 of N4606 for C++.  C seems to provide that an uninitialised
variable may hold a trap representation, but it may equally well have a
valid (unknown) value in it, which is in fact what will happen on 99%
or architectures and all those running C++.  For the latter, these can
be evaluated, say by copying.  §8.6/12 of N4606 on the other hand
provides for blanket undefined behaviour for any copying or other
evaluation of an uninitialized object of built-in type which is not an
unsigned narrow character (unsigned char, and char where char is
unsigned).

I don't like the way C++ sprays around undefined behaviour at the
slightest provocation.  Unions are another example.

Chris

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

#44814

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> writes:

> [...] Moving on from indeterminate values arising from padding to
> indeterminate values arising from uninitialized built-in types, C
> appears to do this much better than the proposal in what is now
> section 8.6/12 of N4606 for C++.  C seems to provide that an
> uninitialised variable may hold a trap representation, but it may
> equally well have a valid (unknown) value in it,

The rule in C11 is just slightly more complicated, but that's
basically right.

> which is in fact
> what will happen on 99% or architectures and all those running
> C++.  For the latter, these can be evaluated, say by copying.
> Section 8.6/12 of N4606 on the other hand provides for blanket
> undefined behaviour for any copying or other evaluation of an
> uninitialized object of built-in type which is not an unsigned
> narrow character (unsigned char, and char where char is unsigned).

I just read through these.  Appalling.

For those who enjoy dark humor, it's amusing to note how these
passages increase the divergence between C++ and C:  they make UB
in C++ for some cases that are defined in C, and they define
behavior in C++ for some cases that are UB in C.  How perfect is
that?

> I don't like the way C++ sprays around undefined behaviour at the
> slightest provocation.  Unions are another example.

I am sorry to say that I wholeheartedly agree.  What C does is
bad enough, and based on a few areas I've looked at recently it
looks like C++ is worse.

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

#44649

On 8/31/2016 1:29 PM, David Brown wrote:
> On 31/08/16 17:06, Manfred wrote:
>> On 8/31/2016 4:22 PM, David Brown wrote:
>>>> Moreover, the guaranteed ordering of a, b, c, d needs to be verified
>>>> with the standard:
>>>> iso 9.2.13 (draft 2014-11-19):
>>>> "Nonstatic data members of a (non-union) class with the same access
>>>> control (Clause 11) are allocated so that later members have higher
>>>> addresses within a class object. The order of allocation of non-static
>>>> data members with different access control is unspecified (Clause 11).
>>>> Implementation alignment requirements might cause two adjacent members
>>>> not to be allocated immediately after each other; so might requirements
>>>> for space for managing virtual functions (10.3) and virtual base
>>>> classes
>>>> (10.1)."
>>>
>>> And note that at least one major compiler - gcc - /did/ re-organise the
>>> ordering in structs when appropriate optimisation flags were enabled.
>>> It would not do so if you took addresses like this, and the optimisation
>>> has been removed in later versions of gcc (because it played badly with
>>> link-time optimisation), but compilers might make such re-organisations
>>> in the future.
>>>
>>> Of course, individual implementations might guarantee that this works,
>>> even though the standards don't.
>>>
>> Data members ordering is guaranteed by the standard, but objections
>> still hold in that, besides packing issues, the same standard in
>> principle allows for:
>> - interleaving of data members with different access control, so that a
>> private member may fall in between a bunch of public ones.
>> - "space for managing virtual functions and virtual base classes" to
>> fall anywhere.
>> Maybe your proposal of union+array could prevent this?
>>
> 
> Apparently, you are not allowed to access the different parts of the
> union as I had thought.  My knowledge of such details in C++ is a good
> deal less than my knowledge of C, and my knowledge of C has holes too!
> 
> However, the standard does not guarantee that data members are ordered
> in the same way as they are declared in the struct - it guarantees that
> they /appear/ that way to any code with defined behaviour.  If code does
> not do anything that might be influenced by the ordering, or the code
> that is dependent on the order has undefined behaviour (as in this
> case), then the compiler /can/ re-order the data members.  This is all
> part of the "as if" rule - compilers can generate anything they want, as
> long as the code runs "as if" it followed the abstract machine and C or
> C++ rules directly.
>

Incorrect.  Order of data members in the struct must be as they are
declared in the struct.  There may be padding between the members, but
the order cannot change.

Compilers cannot "generate anything they want as long as the runs as
if".  They are bound by other rules.

> So if you have a struct, and use things like the "offsetof" macro on its
> fields, the compiler is going to have to allocate members in the
> specified order.  But if you have a "struct { int a; int b; }" used as a
> local variable without ever referring to their addresses, not only can
> the compiler swap a and b, but it can put them in registers, or even
> omit one of the members altogether if it can be "optimised away".
> 
> 

That is not the only reason compilers have to allocate members in the
specified order.  Reading/writing binary files is another.

And the compilation of source file "A" has no idea if the compilation of
source file "B" uses any of the above.  So even though "A" doesn't use
any of these features, the compiler cannot reorder members of a struct.

And the same is true in C.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#44653

On 01/09/16 05:17, Jerry Stuckle wrote:
> On 8/31/2016 1:29 PM, David Brown wrote:
>> On 31/08/16 17:06, Manfred wrote:
>>> On 8/31/2016 4:22 PM, David Brown wrote:
>>>>> Moreover, the guaranteed ordering of a, b, c, d needs to be verified
>>>>> with the standard:
>>>>> iso 9.2.13 (draft 2014-11-19):
>>>>> "Nonstatic data members of a (non-union) class with the same access
>>>>> control (Clause 11) are allocated so that later members have higher
>>>>> addresses within a class object. The order of allocation of non-static
>>>>> data members with different access control is unspecified (Clause 11).
>>>>> Implementation alignment requirements might cause two adjacent members
>>>>> not to be allocated immediately after each other; so might requirements
>>>>> for space for managing virtual functions (10.3) and virtual base
>>>>> classes
>>>>> (10.1)."
>>>>
>>>> And note that at least one major compiler - gcc - /did/ re-organise the
>>>> ordering in structs when appropriate optimisation flags were enabled.
>>>> It would not do so if you took addresses like this, and the optimisation
>>>> has been removed in later versions of gcc (because it played badly with
>>>> link-time optimisation), but compilers might make such re-organisations
>>>> in the future.
>>>>
>>>> Of course, individual implementations might guarantee that this works,
>>>> even though the standards don't.
>>>>
>>> Data members ordering is guaranteed by the standard, but objections
>>> still hold in that, besides packing issues, the same standard in
>>> principle allows for:
>>> - interleaving of data members with different access control, so that a
>>> private member may fall in between a bunch of public ones.
>>> - "space for managing virtual functions and virtual base classes" to
>>> fall anywhere.
>>> Maybe your proposal of union+array could prevent this?
>>>
>>
>> Apparently, you are not allowed to access the different parts of the
>> union as I had thought.  My knowledge of such details in C++ is a good
>> deal less than my knowledge of C, and my knowledge of C has holes too!
>>
>> However, the standard does not guarantee that data members are ordered
>> in the same way as they are declared in the struct - it guarantees that
>> they /appear/ that way to any code with defined behaviour.  If code does
>> not do anything that might be influenced by the ordering, or the code
>> that is dependent on the order has undefined behaviour (as in this
>> case), then the compiler /can/ re-order the data members.  This is all
>> part of the "as if" rule - compilers can generate anything they want, as
>> long as the code runs "as if" it followed the abstract machine and C or
>> C++ rules directly.
>>
> 
> Incorrect.  Order of data members in the struct must be as they are
> declared in the struct.  There may be padding between the members, but
> the order cannot change.
> 
> Compilers cannot "generate anything they want as long as the runs as
> if".  They are bound by other rules.

No, to a very large extent they /can/ generate anything they want - as
long as the code runs "as if" it followed the rules strictly.  This is
one of the key points for an optimising compiler.

> 
>> So if you have a struct, and use things like the "offsetof" macro on its
>> fields, the compiler is going to have to allocate members in the
>> specified order.  But if you have a "struct { int a; int b; }" used as a
>> local variable without ever referring to their addresses, not only can
>> the compiler swap a and b, but it can put them in registers, or even
>> omit one of the members altogether if it can be "optimised away".
>>
>>
> 
> That is not the only reason compilers have to allocate members in the
> specified order.  Reading/writing binary files is another.

And how do you intend to read or write binary data between a file and a
struct, without taking the address of that struct?  When you are doing
operations like that, the compiler must make sure the ordering of the
struct members follows the rules of the language (C or C++), and the ABI
requirements of the platform.

But when code does nothing (with defined behaviour) that could be
influenced by the ordering of the struct members, the compiler is free
to re-order those members.  And with function-local data, it might well
do exactly that.

> 
> And the compilation of source file "A" has no idea if the compilation of
> source file "B" uses any of the above.  So even though "A" doesn't use
> any of these features, the compiler cannot reorder members of a struct.

The compiler can only re-order data if it can be sure it is safe to do
so - that is the same as for any optimisation.  Since it does not know
what "B" will do with the data in "A", then typically it would not be
able to re-arrange the members.  However, an implementation /could/ do
so - as long as it tracks this difference, such as via information in
the object file files, and ensures the complete result runs "as if" the
order was fixed.  That's not going to happen in a compiler for big
systems, where object file formats follow known ABIs, but it is
perfectly allowed for specialised tools.

> 
> And the same is true in C.
> 

That, at least, is correct - the rules here for C and C++ are the same.

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

#44698

On 9/1/2016 3:35 AM, David Brown wrote:
> On 01/09/16 05:17, Jerry Stuckle wrote:
>> On 8/31/2016 1:29 PM, David Brown wrote:
>>> On 31/08/16 17:06, Manfred wrote:
>>>> On 8/31/2016 4:22 PM, David Brown wrote:
>>>>>> Moreover, the guaranteed ordering of a, b, c, d needs to be verified
>>>>>> with the standard:
>>>>>> iso 9.2.13 (draft 2014-11-19):
>>>>>> "Nonstatic data members of a (non-union) class with the same access
>>>>>> control (Clause 11) are allocated so that later members have higher
>>>>>> addresses within a class object. The order of allocation of non-static
>>>>>> data members with different access control is unspecified (Clause 11).
>>>>>> Implementation alignment requirements might cause two adjacent members
>>>>>> not to be allocated immediately after each other; so might requirements
>>>>>> for space for managing virtual functions (10.3) and virtual base
>>>>>> classes
>>>>>> (10.1)."
>>>>>
>>>>> And note that at least one major compiler - gcc - /did/ re-organise the
>>>>> ordering in structs when appropriate optimisation flags were enabled.
>>>>> It would not do so if you took addresses like this, and the optimisation
>>>>> has been removed in later versions of gcc (because it played badly with
>>>>> link-time optimisation), but compilers might make such re-organisations
>>>>> in the future.
>>>>>
>>>>> Of course, individual implementations might guarantee that this works,
>>>>> even though the standards don't.
>>>>>
>>>> Data members ordering is guaranteed by the standard, but objections
>>>> still hold in that, besides packing issues, the same standard in
>>>> principle allows for:
>>>> - interleaving of data members with different access control, so that a
>>>> private member may fall in between a bunch of public ones.
>>>> - "space for managing virtual functions and virtual base classes" to
>>>> fall anywhere.
>>>> Maybe your proposal of union+array could prevent this?
>>>>
>>>
>>> Apparently, you are not allowed to access the different parts of the
>>> union as I had thought.  My knowledge of such details in C++ is a good
>>> deal less than my knowledge of C, and my knowledge of C has holes too!
>>>
>>> However, the standard does not guarantee that data members are ordered
>>> in the same way as they are declared in the struct - it guarantees that
>>> they /appear/ that way to any code with defined behaviour.  If code does
>>> not do anything that might be influenced by the ordering, or the code
>>> that is dependent on the order has undefined behaviour (as in this
>>> case), then the compiler /can/ re-order the data members.  This is all
>>> part of the "as if" rule - compilers can generate anything they want, as
>>> long as the code runs "as if" it followed the abstract machine and C or
>>> C++ rules directly.
>>>
>>
>> Incorrect.  Order of data members in the struct must be as they are
>> declared in the struct.  There may be padding between the members, but
>> the order cannot change.
>>
>> Compilers cannot "generate anything they want as long as the runs as
>> if".  They are bound by other rules.
> 
> No, to a very large extent they /can/ generate anything they want - as
> long as the code runs "as if" it followed the rules strictly.  This is
> one of the key points for an optimising compiler.
>

They can "to a very large extent".  But this does NOT include reordering
members of a struct.  The most they can do is add padding between
members.  That is not reordering.

>>
>>> So if you have a struct, and use things like the "offsetof" macro on its
>>> fields, the compiler is going to have to allocate members in the
>>> specified order.  But if you have a "struct { int a; int b; }" used as a
>>> local variable without ever referring to their addresses, not only can
>>> the compiler swap a and b, but it can put them in registers, or even
>>> omit one of the members altogether if it can be "optimised away".
>>>
>>>
>>
>> That is not the only reason compilers have to allocate members in the
>> specified order.  Reading/writing binary files is another.
> 
> And how do you intend to read or write binary data between a file and a
> struct, without taking the address of that struct?  When you are doing
> operations like that, the compiler must make sure the ordering of the
> struct members follows the rules of the language (C or C++), and the ABI
> requirements of the platform.
> 

Taking the address of the struct is not the same as taking the address
of the members.  You are not using offsetof(), for instance.

> But when code does nothing (with defined behaviour) that could be
> influenced by the ordering of the struct members, the compiler is free
> to re-order those members.  And with function-local data, it might well
> do exactly that.
> 

Incorrect (as you are incorrect when you claimed this in C):  From the
standard, section 9.2, note 13:

"Nonstatic data members of a (non-union) class with the same access
control (Clause 11) are allocated so that later members have higher
addresses within a class object."

And don't get your panties in a wad over the use of the term "class".
The section is referring to classes, unions and structs.

>>
>> And the compilation of source file "A" has no idea if the compilation of
>> source file "B" uses any of the above.  So even though "A" doesn't use
>> any of these features, the compiler cannot reorder members of a struct.
> 
> The compiler can only re-order data if it can be sure it is safe to do
> so - that is the same as for any optimisation.  Since it does not know
> what "B" will do with the data in "A", then typically it would not be
> able to re-arrange the members.  However, an implementation /could/ do
> so - as long as it tracks this difference, such as via information in
> the object file files, and ensures the complete result runs "as if" the
> order was fixed.  That's not going to happen in a compiler for big
> systems, where object file formats follow known ABIs, but it is
> perfectly allowed for specialised tools.
> 

Not within a struct it cannot.  See above.

>>
>> And the same is true in C.
>>
> 
> That, at least, is correct - the rules here for C and C++ are the same.
> 

Yup, the compiler can't do it in C, either.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#44707

On Thursday, September 1, 2016 at 12:34:23 PM UTC-7, Jerry Stuckle wrote:
> On 9/1/2016 3:35 AM, David Brown wrote:
> > On 01/09/16 05:17, Jerry Stuckle wrote:

> >> Compilers cannot "generate anything they want as long as the runs as
> >> if".  They are bound by other rules.
> > 
> > No, to a very large extent they /can/ generate anything they want - as
> > long as the code runs "as if" it followed the rules strictly.  This is
> > one of the key points for an optimising compiler.
> >
> 
> They can "to a very large extent".  But this does NOT include reordering
> members of a struct.  The most they can do is add padding between
> members.  That is not reordering.

Why do you think that structure member layout is immune to the as-if rule?

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

#44715

On 9/1/2016 4:50 PM, me wrote:
> On Thursday, September 1, 2016 at 12:34:23 PM UTC-7, Jerry Stuckle wrote:
>> On 9/1/2016 3:35 AM, David Brown wrote:
>>> On 01/09/16 05:17, Jerry Stuckle wrote:
> 
>>>> Compilers cannot "generate anything they want as long as the runs as
>>>> if".  They are bound by other rules.
>>>
>>> No, to a very large extent they /can/ generate anything they want - as
>>> long as the code runs "as if" it followed the rules strictly.  This is
>>> one of the key points for an optimising compiler.
>>>
>>
>> They can "to a very large extent".  But this does NOT include reordering
>> members of a struct.  The most they can do is add padding between
>> members.  That is not reordering.
> 
> Why do you think that structure member layout is immune to the as-if rule?
> 

Because the standard says so.  Read the entire message.  It contains the
quote from the standard.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#44721

On Thursday, September 1, 2016 at 6:01:28 PM UTC-7, Jerry Stuckle wrote:
> On 9/1/2016 4:50 PM, me wrote:
> > On Thursday, September 1, 2016 at 12:34:23 PM UTC-7, Jerry Stuckle wrote:
> >> On 9/1/2016 3:35 AM, David Brown wrote:
> >>> On 01/09/16 05:17, Jerry Stuckle wrote:
> > 
> >>>> Compilers cannot "generate anything they want as long as the runs as
> >>>> if".  They are bound by other rules.
> >>>
> >>> No, to a very large extent they /can/ generate anything they want - as
> >>> long as the code runs "as if" it followed the rules strictly.  This is
> >>> one of the key points for an optimising compiler.
> >>>
> >>
> >> They can "to a very large extent".  But this does NOT include reordering
> >> members of a struct.  The most they can do is add padding between
> >> members.  That is not reordering.
> > 
> > Why do you think that structure member layout is immune to the as-if rule?
> > 
> 
> Because the standard says so.  Read the entire message.  It contains the
> quote from the standard.
> 

I did.

The standard also says that the as-if rule over-rides everything else in
the standard, and that only observable behaviour of the program need be
considered. So again, why is structure member layout _different_ in this
respect? There are all sorts of things that I could quote from the standard,
specifying how the abstract machine must do things, but none of which matter
one jot as long as the program produces the output specified.

Given these two programs:
<program 1>
#include <cstdio>
struct S { int a; int b; };
struct S s = { 1, 2 };
int main(void){ printf("%d\n", s.a); return 0; }
</program 1>
and
<program 2>
#include <cstdio>
struct S { int b; int a; };
struct S s = { 2, 1 };
int main(void) { printf("%d\n", s.a); return 0; }
<program 2>

If a compiler produced exactly, bit-for-bit, the same executable for
these two programs, would you complain to the vendor that they were
disobeying 9.2.13? What would you say to convince them that the as-if
rule _didn't_ apply?

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

#44722

On 9/1/2016 10:02 PM, me wrote:
> On Thursday, September 1, 2016 at 6:01:28 PM UTC-7, Jerry Stuckle wrote:
>> On 9/1/2016 4:50 PM, me wrote:
>>> On Thursday, September 1, 2016 at 12:34:23 PM UTC-7, Jerry Stuckle wrote:
>>>> On 9/1/2016 3:35 AM, David Brown wrote:
>>>>> On 01/09/16 05:17, Jerry Stuckle wrote:
>>>
>>>>>> Compilers cannot "generate anything they want as long as the runs as
>>>>>> if".  They are bound by other rules.
>>>>>
>>>>> No, to a very large extent they /can/ generate anything they want - as
>>>>> long as the code runs "as if" it followed the rules strictly.  This is
>>>>> one of the key points for an optimising compiler.
>>>>>
>>>>
>>>> They can "to a very large extent".  But this does NOT include reordering
>>>> members of a struct.  The most they can do is add padding between
>>>> members.  That is not reordering.
>>>
>>> Why do you think that structure member layout is immune to the as-if rule?
>>>
>>
>> Because the standard says so.  Read the entire message.  It contains the
>> quote from the standard.
>>
> 
> I did.
> 
> The standard also says that the as-if rule over-rides everything else in
> the standard, and that only observable behaviour of the program need be
> considered. So again, why is structure member layout _different_ in this
> respect? There are all sorts of things that I could quote from the standard,
> specifying how the abstract machine must do things, but none of which matter
> one jot as long as the program produces the output specified.
>

And where does it say the rule can override such structures?  You are
misreading the standard.  The as-if rule applies to execution, not
memory layout.

> Given these two programs:
> <program 1>
> #include <cstdio>
> struct S { int a; int b; };
> struct S s = { 1, 2 };
> int main(void){ printf("%d\n", s.a); return 0; }
> </program 1>
> and
> <program 2>
> #include <cstdio>
> struct S { int b; int a; };
> struct S s = { 2, 1 };
> int main(void) { printf("%d\n", s.a); return 0; }
> <program 2>
> 
> If a compiler produced exactly, bit-for-bit, the same executable for
> these two programs, would you complain to the vendor that they were
> disobeying 9.2.13? What would you say to convince them that the as-if
> rule _didn't_ apply?
> 

Yes, because they are.  What would YOU say to convince someone it is OK?

If your interpretation were correct, there would be no need for 9.2.13.
But it's there - so there must be a reason.  Maybe it's because you
don't understand the as-if rule.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#44738

On Thursday, September 1, 2016 at 7:17:16 PM UTC-7, Jerry Stuckle wrote:
> On 9/1/2016 10:02 PM, me wrote:
> > On Thursday, September 1, 2016 at 6:01:28 PM UTC-7, Jerry Stuckle wrote:
> >> On 9/1/2016 4:50 PM, me wrote:
> >>> On Thursday, September 1, 2016 at 12:34:23 PM UTC-7, Jerry Stuckle wrote:
> >>>> On 9/1/2016 3:35 AM, David Brown wrote:
> >>>>> On 01/09/16 05:17, Jerry Stuckle wrote:
> >>>
> >>>>>> Compilers cannot "generate anything they want as long as the runs as
> >>>>>> if".  They are bound by other rules.
> >>>>>
> >>>>> No, to a very large extent they /can/ generate anything they want - as
> >>>>> long as the code runs "as if" it followed the rules strictly.  This is
> >>>>> one of the key points for an optimising compiler.
> >>>>>
> >>>>
> >>>> They can "to a very large extent".  But this does NOT include reordering
> >>>> members of a struct.  The most they can do is add padding between
> >>>> members.  That is not reordering.
> >>>
> >>> Why do you think that structure member layout is immune to the as-if rule?
> >>>
> >>
> >> Because the standard says so.  Read the entire message.  It contains the
> >> quote from the standard.
> >>
> > 
> > I did.
> > 
> > The standard also says that the as-if rule over-rides everything else in
> > the standard, and that only observable behaviour of the program need be
> > considered. So again, why is structure member layout _different_ in this
> > respect? There are all sorts of things that I could quote from the standard,
> > specifying how the abstract machine must do things, but none of which matter
> > one jot as long as the program produces the output specified.
> >
> 
> And where does it say the rule can override such structures?  You are
> misreading the standard.  The as-if rule applies to execution, not
> memory layout.

Have _you_ read 1.9.1? "[C]onforming implementations are required to
emulate (only) the observable behavior of the abstract machine as explained
below." Since 9.2.13 .gt. 1.9, clearly it applies to structure member
layout.

> > Given these two programs:
> > <program 1>
> > #include <cstdio>
> > struct S { int a; int b; };
> > struct S s = { 1, 2 };
> > int main(void){ printf("%d\n", s.a); return 0; }
> > </program 1>
> > and
> > <program 2>
> > #include <cstdio>
> > struct S { int b; int a; };
> > struct S s = { 2, 1 };
> > int main(void) { printf("%d\n", s.a); return 0; }
> > <program 2>
> > 
> > If a compiler produced exactly, bit-for-bit, the same executable for
> > these two programs, would you complain to the vendor that they were
> > disobeying 9.2.13? What would you say to convince them that the as-if
> > rule _didn't_ apply?
> > 
> 
> Yes, because they are.  What would YOU say to convince someone it is OK?

My first recourse of course would be to reference 1.9.1. But maybe a
simpler approach would just be "Prove it". I.e., prove that in program 1
the memory address of s.a is higher than s.b, OR prove that in program 2
the memory address of s.a is lower than s.b.

> 
> If your interpretation were correct, there would be no need for 9.2.13.
> But it's there - so there must be a reason.  Maybe it's because you
> don't understand the as-if rule.

Of course it's still needed. It describes certain observable behaviour,
like taking addresses and offsets of struct members. But in the absence
of taking those addresses, I really can't understand how "behaviour"
that is _completely_unobservable_ via standards-mandated means, could
possibly be construed as "observable behaviour".

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

#44749

On 9/2/2016 11:19 AM, me wrote:
> On Thursday, September 1, 2016 at 7:17:16 PM UTC-7, Jerry Stuckle wrote:
>> On 9/1/2016 10:02 PM, me wrote:
>>> On Thursday, September 1, 2016 at 6:01:28 PM UTC-7, Jerry Stuckle wrote:
>>>> On 9/1/2016 4:50 PM, me wrote:
>>>>> On Thursday, September 1, 2016 at 12:34:23 PM UTC-7, Jerry Stuckle wrote:
>>>>>> On 9/1/2016 3:35 AM, David Brown wrote:
>>>>>>> On 01/09/16 05:17, Jerry Stuckle wrote:
>>>>>
>>>>>>>> Compilers cannot "generate anything they want as long as the runs as
>>>>>>>> if".  They are bound by other rules.
>>>>>>>
>>>>>>> No, to a very large extent they /can/ generate anything they want - as
>>>>>>> long as the code runs "as if" it followed the rules strictly.  This is
>>>>>>> one of the key points for an optimising compiler.
>>>>>>>
>>>>>>
>>>>>> They can "to a very large extent".  But this does NOT include reordering
>>>>>> members of a struct.  The most they can do is add padding between
>>>>>> members.  That is not reordering.
>>>>>
>>>>> Why do you think that structure member layout is immune to the as-if rule?
>>>>>
>>>>
>>>> Because the standard says so.  Read the entire message.  It contains the
>>>> quote from the standard.
>>>>
>>>
>>> I did.
>>>
>>> The standard also says that the as-if rule over-rides everything else in
>>> the standard, and that only observable behaviour of the program need be
>>> considered. So again, why is structure member layout _different_ in this
>>> respect? There are all sorts of things that I could quote from the standard,
>>> specifying how the abstract machine must do things, but none of which matter
>>> one jot as long as the program produces the output specified.
>>>
>>
>> And where does it say the rule can override such structures?  You are
>> misreading the standard.  The as-if rule applies to execution, not
>> memory layout.
> 
> Have _you_ read 1.9.1? "[C]onforming implementations are required to
> emulate (only) the observable behavior of the abstract machine as explained
> below." Since 9.2.13 .gt. 1.9, clearly it applies to structure member
> layout.
>  

Yes, and "below" refers to the rest of section 1.9, NOT the entire rest
of the standard.

Additionally, 1.9 refers to "Program Execution".  Not memory layout.

>>> Given these two programs:
>>> <program 1>
>>> #include <cstdio>
>>> struct S { int a; int b; };
>>> struct S s = { 1, 2 };
>>> int main(void){ printf("%d\n", s.a); return 0; }
>>> </program 1>
>>> and
>>> <program 2>
>>> #include <cstdio>
>>> struct S { int b; int a; };
>>> struct S s = { 2, 1 };
>>> int main(void) { printf("%d\n", s.a); return 0; }
>>> <program 2>
>>>
>>> If a compiler produced exactly, bit-for-bit, the same executable for
>>> these two programs, would you complain to the vendor that they were
>>> disobeying 9.2.13? What would you say to convince them that the as-if
>>> rule _didn't_ apply?
>>>
>>
>> Yes, because they are.  What would YOU say to convince someone it is OK?
> 
> My first recourse of course would be to reference 1.9.1. But maybe a
> simpler approach would just be "Prove it". I.e., prove that in program 1
> the memory address of s.a is higher than s.b, OR prove that in program 2
> the memory address of s.a is lower than s.b.
>

And once again you are reading the standard wrong.

>>
>> If your interpretation were correct, there would be no need for 9.2.13.
>> But it's there - so there must be a reason.  Maybe it's because you
>> don't understand the as-if rule.
> 
> Of course it's still needed. It describes certain observable behaviour,
> like taking addresses and offsets of struct members. But in the absence
> of taking those addresses, I really can't understand how "behaviour"
> that is _completely_unobservable_ via standards-mandated means, could
> possibly be construed as "observable behaviour".
> 

Why is it still needed?  It describes no behavior.  It describes memory
layout - which you just said is overridden by 1.9.1.



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#44757

On Friday, September 2, 2016 at 9:39:15 AM UTC-7, Jerry Stuckle wrote:
> On 9/2/2016 11:19 AM, me wrote:
> > On Thursday, September 1, 2016 at 7:17:16 PM UTC-7, Jerry Stuckle wrote:
> >> On 9/1/2016 10:02 PM, me wrote:
> >>> On Thursday, September 1, 2016 at 6:01:28 PM UTC-7, Jerry Stuckle wrote:
> >>>> On 9/1/2016 4:50 PM, me wrote:
> >>>>> On Thursday, September 1, 2016 at 12:34:23 PM UTC-7, Jerry Stuckle wrote:
> >>>>>> On 9/1/2016 3:35 AM, David Brown wrote:
> >>>>>>> On 01/09/16 05:17, Jerry Stuckle wrote:
> >>>>>
> >>>>>>>> Compilers cannot "generate anything they want as long as the runs as
> >>>>>>>> if".  They are bound by other rules.
> >>>>>>>
> >>>>>>> No, to a very large extent they /can/ generate anything they want - as
> >>>>>>> long as the code runs "as if" it followed the rules strictly.  This is
> >>>>>>> one of the key points for an optimising compiler.
> >>>>>>>
> >>>>>>
> >>>>>> They can "to a very large extent".  But this does NOT include reordering
> >>>>>> members of a struct.  The most they can do is add padding between
> >>>>>> members.  That is not reordering.
> >>>>>
> >>>>> Why do you think that structure member layout is immune to the as-if rule?
> >>>>>
> >>>>
> >>>> Because the standard says so.  Read the entire message.  It contains the
> >>>> quote from the standard.
> >>>>
> >>>
> >>> I did.
> >>>
> >>> The standard also says that the as-if rule over-rides everything else in
> >>> the standard, and that only observable behaviour of the program need be
> >>> considered. So again, why is structure member layout _different_ in this
> >>> respect? There are all sorts of things that I could quote from the standard,
> >>> specifying how the abstract machine must do things, but none of which matter
> >>> one jot as long as the program produces the output specified.
> >>>
> >>
> >> And where does it say the rule can override such structures?  You are
> >> misreading the standard.  The as-if rule applies to execution, not
> >> memory layout.
> > 
> > Have _you_ read 1.9.1? "[C]onforming implementations are required to
> > emulate (only) the observable behavior of the abstract machine as explained
> > below." Since 9.2.13 .gt. 1.9, clearly it applies to structure member
> > layout.
> >  
> 
> Yes, and "below" refers to the rest of section 1.9, NOT the entire rest
> of the standard.
> 
> Additionally, 1.9 refers to "Program Execution".  Not memory layout.

Footnote 5) explicitly says that _any_ requirement
of the standard can be ignored as long as the observable behaviour
is correct. Yes, it's only a footnote, but clearly conveys the intent
of 1.9.1.

1.9.8 defines "observable behavior" in the obvious manner, which does
_not_ include (explicitly) anything to do with memory layout.

Finally (admittedly this is a less-than-language-lawyerly argument),
I think that all the guff about observable behaviour, as-if rule,
abstract machines, is about ensuring that the program produces
well-defined output and does what we think programs should do. We
want the correct prompts to show up for the user, we want the correct
bits to show up in files, etc., etc. To insist that the standard
would even _bother_ to care about struct layout except as it affects
observable behaviour seems utterly useless. (And this is supported
by footnote 5).

> >>> Given these two programs:
> >>> <program 1>
> >>> #include <cstdio>
> >>> struct S { int a; int b; };
> >>> struct S s = { 1, 2 };
> >>> int main(void){ printf("%d\n", s.a); return 0; }
> >>> </program 1>
> >>> and
> >>> <program 2>
> >>> #include <cstdio>
> >>> struct S { int b; int a; };
> >>> struct S s = { 2, 1 };
> >>> int main(void) { printf("%d\n", s.a); return 0; }
> >>> <program 2>
> >>>
> >>> If a compiler produced exactly, bit-for-bit, the same executable for
> >>> these two programs, would you complain to the vendor that they were
> >>> disobeying 9.2.13? What would you say to convince them that the as-if
> >>> rule _didn't_ apply?
> >>>
> >>
> >> Yes, because they are.  What would YOU say to convince someone it is OK?
> > 
> > My first recourse of course would be to reference 1.9.1. But maybe a
> > simpler approach would just be "Prove it". I.e., prove that in program 1
> > the memory address of s.a is higher than s.b, OR prove that in program 2
> > the memory address of s.a is lower than s.b.
> >
> 
> And once again you are reading the standard wrong.

Okay, please explain how your correct reading is a counterargument to
my "prove it" argument. I.e., what statement in the standard _precludes_
both those programs producing identical executables. _Prove_ that the
addresses of the struct members are _not_ as the standard mandates.

> >>
> >> If your interpretation were correct, there would be no need for 9.2.13.
> >> But it's there - so there must be a reason.  Maybe it's because you
> >> don't understand the as-if rule.
> > 
> > Of course it's still needed. It describes certain observable behaviour,
> > like taking addresses and offsets of struct members. But in the absence
> > of taking those addresses, I really can't understand how "behaviour"
> > that is _completely_unobservable_ via standards-mandated means, could
> > possibly be construed as "observable behaviour".
> > 
> 
> Why is it still needed?  It describes no behavior.  It describes memory
> layout - which you just said is overridden by 1.9.1.

I phrased that poorly. _If_ it affects observable behaviour, i.e., _if_
addresses are taken or member offsets are used, _then_ the implementation
must take 9.2.13 into account to ensure that the observable behaviour
is correct. But 1.9.1 (plus footnote 5) says that if there is _no_ affect
on observable behaviour (as in my programs above), the implementation
can do any darn thing it pleases with struct layout.

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

#44761

On 9/2/2016 3:26 PM, me wrote:
--- nothing worth responding to.

You obviously are even more stoopid than some of the other trolls here.
I'm not even going to bother with you any more.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#44763

On Friday, September 2, 2016 at 1:38:14 PM UTC-7, Jerry Stuckle wrote:
> On 9/2/2016 3:26 PM, me wrote:
> --- nothing worth responding to.
> 
> You obviously are even more stoopid than some of the other trolls here.
> I'm not even going to bother with you any more.

Classic! I'm sure that will convince readers who can go back and look at
the history ...

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

#44766

On Friday, September 2, 2016 at 1:51:57 PM UTC-7, me wrote:
> On Friday, September 2, 2016 at 1:38:14 PM UTC-7, Jerry Stuckle wrote:
> > On 9/2/2016 3:26 PM, me wrote:
> > --- nothing worth responding to.
> > 
> > You obviously are even more stoopid than some of the other trolls here.
> > I'm not even going to bother with you any more.
> 
> Classic! I'm sure that will convince readers who can go back and look at
> the history ...

Oh, and I humbly thank you for the honour of adding me to the list of
contributors you've called "stoopid".

I had a speech prepared ... now where are my notes ...?

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

#44770

On 9/2/2016 4:51 PM, me wrote:
> On Friday, September 2, 2016 at 1:38:14 PM UTC-7, Jerry Stuckle wrote:
>> On 9/2/2016 3:26 PM, me wrote:
>> --- nothing worth responding to.
>>
>> You obviously are even more stoopid than some of the other trolls here.
>> I'm not even going to bother with you any more.
> 
> Classic! I'm sure that will convince readers who can go back and look at
> the history ...
> 
> 

They sure can.  And they will see what you really are.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#44765

On 2.09.2016 22:26, me wrote:
> But 1.9.1 (plus footnote 5) says that if there is _no_ affect
> on observable behaviour (as in my programs above), the implementation
> can do any darn thing it pleases with struct layout.

I have got an impression that the most common thing which might happen 
with a struct is that the compiler decides to place it into registers 
altogether and there is no layout to speak of (what is the padding 
between EAX and EBX?).

In regard of unions this becomes quite interesting. I imagine the 
compiler might easily place the different union members in different 
registers (except for the common initial sequence, if any). Using 
different registers might make a lot of sense if one member is holding 
integers and the other floating-point numbers, for example. I guess the 
only thing which might hold the compiler developers back here is that 
the union has a long tradition of being illegally abused for type-punning.

Cheers
Paavo

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

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

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

csiph-web