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

Groups > comp.std.c > #1846

Re: Unsequenced Side Effects on the Same Union

Show all headers | View raw

On Wed, 16 Jan 2013 11:04:34 -0500, James Kuyper wrote:
> On 01/16/2013 09:55 AM, Nick Bowler wrote:
>> On Tue, 15 Jan 2013 22:32:27 -0500, Shao Miller wrote:
>>> #include <stdio.h>
>>>
>>>    void func1(void * vp1, void * vp2) {
>>>        int * ip;
>>>        double * dp;
>>>
>>>        /* Populate ip and dp? */
>>>        if (!vp1 && !vp2) {
>>>            func1(&ip, &dp);
>>>
>>>            /*
>>>             * 6.5p2: Unsequenced side effects
>>>             * on the same... Scalar?
>>>             */
>>>            printf("%f\n", (*ip = 42) + (*dp = 3.14));
>>>          }
>>>
>>>        /* Self-called? */
>>>        if (vp1 && vp2) {
>>>            /* Aliasing shoved down here */
>>>            static union {
>>>                int i;
>>>                double d;
>>>              } u;
>>>            *(int **) vp1 = &u.i;
>>>            *(double **) vp2 = &u.d;
>>>          }
>>>      }
>>>
>>>    int main(void) { func1(NULL, NULL); return 0; }
>>>
>>> Sorry all, I'm puzzled...  This surely yields undefined behaviour, but 
>>> why, in C11?  6.5p2 changed from that of C99.  Is it because one of the 
>>> '+' operands could establish an effective type before the other?
>> 
>> I have a feeling that when the authors wrote "scalar object" in n1570
>> 6.5p2 they had something specific in mind, but the term does not appear
>> to be defined anywhere in the standard.  The term also is not in the
>> index.  Perhaps this was corrected in the final standard which I do not
>> have a copy of.
> 
> A "scalar object" should simply mean an "object of scalar type".

Well, "object with scalar type" is clearly an inappropriate definition
for "scalar object".  "Object with atomic, qualified or unqualified
scalar type" would be a bit better, but that definition still seems
inappropriate for the usage in Annex K (see below).  This is exactly
why terms like this need to be defined.

>> "Scalar object" is also used in 5.1.2.4p14, where context suggests that
>> it at least excludes bit-fields. ...
> 
> You're right, and I think that's a mistake. All bit-fields with non-zero
> widths are objects which have scalar types.
> 
>> ...  It appears again in 5.1.2.4p19 with
>> context suggesting that it includes objects with atomic types. ...
> 
> Yes, any object with an atomic scalar type would qualify.

Assuming your "simple" definition is changed as per above, sure.

>>  ... It is also used a couple times in Annex K, with context
>>  suggesting that it does not include objects that are elements of
>>  arrays.
> 
> Yes, array types are not scalar.

I didn't say array types, and neither does Annex K.  I said *elements of
arrays*, which can most certainly be objects with atomic, qualified or
unqualified scalar type.

>> At the very least, the undefined term "scalar object" appears to
>> have absolutely nothing to do with the confusingly similarly-named
>> (and actually defined) "scalar type".  Fun.
> 
> The only problem I can see with my interpretation is 5.1.2.4p14, which I
> think was a mistake. Do you have any other reason for believing that a
> "scalar object" means anything other than an "object with scalar type"?

In addition to what's said above, this still leaves the OP: how are
unions (which most certainly do *not* have atomic, qualified or
unqualified scalar type) to be treated with respect to 6.5p2?  I suspect
the authors intended them to be included, since they *were* covered by
6.5p2 in previous versions of the standard.

Cheers,
  Nick

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Unsequenced Side Effects on the Same Union Shao Miller <sha0.miller@gmail.com> - 2013-01-15 22:32 -0500
  Re: Unsequenced Side Effects on the Same Union Nick Bowler <nbowler@draconx.ca> - 2013-01-16 14:55 +0000
    Re: Unsequenced Side Effects on the Same Union Shao Miller <sha0.miller@gmail.com> - 2013-01-16 10:53 -0500
    Re: Unsequenced Side Effects on the Same Union James Kuyper <jameskuyper@verizon.net> - 2013-01-16 11:04 -0500
      Re: Unsequenced Side Effects on the Same Union Nick Bowler <nbowler@draconx.ca> - 2013-01-16 20:56 +0000
        Re: Unsequenced Side Effects on the Same Union Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-17 13:21 -0800
          Re: Unsequenced Side Effects on the Same Union Shao Miller <sha0.miller@gmail.com> - 2013-01-17 17:50 -0500
            Re: Unsequenced Side Effects on the Same Union Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-18 11:25 -0800
              Re: Unsequenced Side Effects on the Same Union Shao Miller <sha0.miller@gmail.com> - 2013-01-18 15:07 -0500

csiph-web