www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4935] New: std.bitmanip: bitfields!() template with trailing unnamed field does not work

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4935

           Summary: std.bitmanip: bitfields!() template with trailing
                    unnamed field does not work
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: ah08010-d yahoo.com


--- Comment #0 from Austin Hastings <ah08010-d yahoo.com> 2010-09-24 09:00:16
PDT ---
Despite the documentation in the library reference manual, a nameless field
cannot be set as the "last" entry in a list of bit fields:

This code:
==========
module scratch;
import std.bitmanip;

version(unittest) {
    void main() { }
}

struct S {
    mixin(bitfields!(
        uint, "some", 4,
    uint, "", 4                     
    ));
}
==========
Produces this error:
==========
$ dmd -unittest -run bronze/util/scratch.d
bronze\util\scratch.d(14): Error: variable scratch.S.some conflicts with
function scratch.S.some at bronze\util\scratch.d(12)
==========
Strangely, leading nameless fields are okay. This code compiles fine:
==========
struct S {
    mixin(bitfields!(
        uint, "", 1,
        uint, "", 1,
        uint, "some", 4,
        uint, "last", 2                 
    ));
}
==========

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 24 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4935


Mitch Hayenga <mitch.hayenga gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mitch.hayenga gmail.com


--- Comment #1 from Mitch Hayenga <mitch.hayenga gmail.com> 2010-09-24 15:38:13
PDT ---
Ahh, I hit this myself a few days ago.  My fields are now named "ignore1",
"ignroe2", etc.  I thought it was maybe my mistake because I was trying to do
something like...

struct Instruction{
  union{
    mixin(bitfields!(
      ubyte, "imm", 4,
      ubyte, "rot", 4,
      ubyte, "",    4,
      ubyte, "opcode", 4));

    // Read the bottom 8 bits as a longer immediate
    mixin(bitfields!( 
      ubyte, "imm8", 8,
      ubyte, "", 8));
  }
}

And was unsure about bitfields support within union type structures.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 24 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4935



--- Comment #2 from Austin Hastings <ah08010-d yahoo.com> 2010-09-24 18:01:07
PDT ---
Entertainingly, this is the "real" code I was trying to work on:

union Instruction {
    ushort raw;

    // Basic opcode + data
    mixin(bitfields!(
                 Opcode, "opcode", 7,
                 uint, "rest", 9));

Is it only people working with opcodes that want to use bitfields? :)

Also, I think I'm going to request that repeated bitfield definitions be
allowed if they are identical - I'd like to redeclare "opcode" rather than "".

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 24 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4935


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei metalanguage.com
         AssignedTo|nobody puremagic.com        |andrei metalanguage.com


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 24 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4935


Era Scarecrow <rtcvb32 yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rtcvb32 yahoo.com


--- Comment #3 from Era Scarecrow <rtcvb32 yahoo.com> 2012-08-01 07:58:42 PDT
---
I was unable to duplicate this problem, so either DMD already fixed some bug,
or my patches already fixed it.

 And was unsure about bitfields support within union type structures.
Inside a union it should be fine, as only one variable is made that's accessible (although enums are present). If those give you trouble, you can use bitfieldsOn (in my branch) to specify a specific variable elsewhere that you want to use for your source. Once the pull is accepted I'm changing this status to resolved. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4935



--- Comment #4 from Andrei Alexandrescu <andrei erdani.com> 2013-02-26 09:06:09
PST ---
 Era: what pull are you referring to?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 26 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4935


safety0ff.bugz <safety0ff.bugz gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |safety0ff.bugz gmail.com


--- Comment #5 from safety0ff.bugz <safety0ff.bugz gmail.com> 2013-10-05
09:26:00 PDT ---
(In reply to comment #4)
  Era: what pull are you referring to?
He seems to have been referring to pull requests: 1045, 719, 734 and 740 (all closed unmerged.) This seems to have been fixed prior to 2.060, I'll end up writing a unittest to make sure it stays that way. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 05 2013