Structured bindings seem to allow non-const references to a bitfield

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Structured bindings seem to allow non-const references to a bitfield

Richard Pennington via cfe-dev
I wasn't sure whether to bring this up here, or to bring it up on the reflector, but I'm not sure if this is a compiler issue or a standards issue.  I read through the structured binding wording, and don't see anything one way or the other, and GCC7 and Clang trunk both allow the following:

struct F {
  unsigned a : 1;
  unsigned b : 2;
  unsigned c : 8;
};

int main() {
  F f;
  f.a = 0;
  f.b = 1;
  f.c = 4;

  auto &b = f.b; // correctly errors on non-const ref to a bitfield

  auto& [d,e,g] = f; // all are references to a bitfield
  d = 3; // Works, but warns about truncation
  c = 3; // Works, no diagnostic
}

Is this intended?  Is this justified by the standard?
-Erich
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Structured bindings seem to allow non-const references to a bitfield

Richard Pennington via cfe-dev
On Wed, Mar 22, 2017 at 12:01 PM, Keane, Erich via cfe-dev <[hidden email]> wrote:
I wasn't sure whether to bring this up here, or to bring it up on the reflector, but I'm not sure if this is a compiler issue or a standards issue.  I read through the structured binding wording, and don't see anything one way or the other, and GCC7 and Clang trunk both allow the following:

struct F {
  unsigned a : 1;
  unsigned b : 2;
  unsigned c : 8;
};

int main() {
  F f;
  f.a = 0;
  f.b = 1;
  f.c = 4;

  auto &b = f.b; // correctly errors on non-const ref to a bitfield

  auto& [d,e,g] = f; // all are references to a bitfield

The only reference here is an unnamed reference to `f`.  None of `d`, `e`, `g` is a reference.  `d` is another name for `f.a`, and similarly for `e` and `g`.
 
  d = 3; // Works, but warns about truncation
  c = 3; // Works, no diagnostic
}

Is this intended?  Is this justified by the standard?
 
The behavior you describe appears correct (and unsurprising to me), apart from the assumption that these are references; they're "structured bindings", not references.

-- James


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Structured bindings seem to allow non-const references to a bitfield

Richard Pennington via cfe-dev

Ok, I guess I didn’t (don’t completely?) ‘get’ that there is a difference between “structured binding alias” and “reference”.  Additionally, if you simply do “auto”, you get copies, right?  So those structured bindings actually introduce new variables, right?

 

From: James Dennett [mailto:[hidden email]]
Sent: Wednesday, March 22, 2017 12:35 PM
To: Keane, Erich <[hidden email]>
Cc: cfe-dev <[hidden email]>
Subject: Re: [cfe-dev] Structured bindings seem to allow non-const references to a bitfield

 

On Wed, Mar 22, 2017 at 12:01 PM, Keane, Erich via cfe-dev <[hidden email]> wrote:

I wasn't sure whether to bring this up here, or to bring it up on the reflector, but I'm not sure if this is a compiler issue or a standards issue.  I read through the structured binding wording, and don't see anything one way or the other, and GCC7 and Clang trunk both allow the following:

struct F {
  unsigned a : 1;
  unsigned b : 2;
  unsigned c : 8;
};

int main() {
  F f;
  f.a = 0;
  f.b = 1;
  f.c = 4;

  auto &b = f.b; // correctly errors on non-const ref to a bitfield

  auto& [d,e,g] = f; // all are references to a bitfield

 

The only reference here is an unnamed reference to `f`.  None of `d`, `e`, `g` is a reference.  `d` is another name for `f.a`, and similarly for `e` and `g`.

 

  d = 3; // Works, but warns about truncation
  c = 3; // Works, no diagnostic
}

Is this intended?  Is this justified by the standard?

 

The behavior you describe appears correct (and unsurprising to me), apart from the assumption that these are references; they're "structured bindings", not references.

 

-- James

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Structured bindings seem to allow non-const references to a bitfield

Richard Pennington via cfe-dev
In reply to this post by Richard Pennington via cfe-dev

Ah, I actually found a more recent version of P0217 (R2 in this case) that mentions bitfields.  Thanks for the clarification!

-Erich

 

From: James Dennett [mailto:[hidden email]]
Sent: Wednesday, March 22, 2017 12:35 PM
To: Keane, Erich <[hidden email]>
Cc: cfe-dev <[hidden email]>
Subject: Re: [cfe-dev] Structured bindings seem to allow non-const references to a bitfield

 

On Wed, Mar 22, 2017 at 12:01 PM, Keane, Erich via cfe-dev <[hidden email]> wrote:

I wasn't sure whether to bring this up here, or to bring it up on the reflector, but I'm not sure if this is a compiler issue or a standards issue.  I read through the structured binding wording, and don't see anything one way or the other, and GCC7 and Clang trunk both allow the following:

struct F {
  unsigned a : 1;
  unsigned b : 2;
  unsigned c : 8;
};

int main() {
  F f;
  f.a = 0;
  f.b = 1;
  f.c = 4;

  auto &b = f.b; // correctly errors on non-const ref to a bitfield

  auto& [d,e,g] = f; // all are references to a bitfield

 

The only reference here is an unnamed reference to `f`.  None of `d`, `e`, `g` is a reference.  `d` is another name for `f.a`, and similarly for `e` and `g`.

 

  d = 3; // Works, but warns about truncation
  c = 3; // Works, no diagnostic
}

Is this intended?  Is this justified by the standard?

 

The behavior you describe appears correct (and unsurprising to me), apart from the assumption that these are references; they're "structured bindings", not references.

 

-- James

 


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Structured bindings seem to allow non-const references to a bitfield

Richard Pennington via cfe-dev
In reply to this post by Richard Pennington via cfe-dev
On Wed, Mar 22, 2017 at 12:38 PM, Keane, Erich <[hidden email]> wrote:

Ok, I guess I didn’t (don’t completely?) ‘get’ that there is a difference between “structured binding alias” and “reference”.  Additionally, if you simply do “auto”, you get copies, right?


You get (at most) one copy, of the value that's being decomposed, and it is unnamed.

-- James

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Structured bindings seem to allow non-const references to a bitfield

Richard Pennington via cfe-dev

AH! I get it now.  The ‘auto’/’const auto’/’auto&’ actually applies to an unnamed Structured Binding object, not as a qualifier to the individual items.  A structured binding is more akin to a named tuple rather than introducing values.

 

I missed that mental model, thank you very much!

-Erich

 

From: James Dennett [mailto:[hidden email]]
Sent: Wednesday, March 22, 2017 1:09 PM
To: Keane, Erich <[hidden email]>
Cc: cfe-dev <[hidden email]>
Subject: Re: [cfe-dev] Structured bindings seem to allow non-const references to a bitfield

 

On Wed, Mar 22, 2017 at 12:38 PM, Keane, Erich <[hidden email]> wrote:

Ok, I guess I didn’t (don’t completely?) ‘get’ that there is a difference between “structured binding alias” and “reference”.  Additionally, if you simply do “auto”, you get copies, right?

 

You get (at most) one copy, of the value that's being decomposed, and it is unnamed.

 

-- James


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...