Given the following code:

/////////////////////
struct X
{
    bit flag;
}

void main ()
{
    X x;
    x.flag = 0 != 0;
}

/////////////////////

dmd outputs: "Internal error: ..\ztc\cgcs.c 213". If X is a union the problem remains, but not if it's a class.

-----------------------
Carlos Santander Bernal

Well, I don't think it should crash, but one would presume bit is not allowed in struct or union types, since it has no meaning in C.

If that's not the case, then it should be.


"Carlos Santander B." <carlos8294@msn.com> wrote in message news:cg41gm$2u2d$1@digitaldaemon.com...
> Given the following code:
>
> /////////////////////
> struct X
> {
>     bit flag;
> }
>
> void main ()
> {
>     X x;
>     x.flag = 0 != 0;
> }
>
> /////////////////////
>
> dmd outputs: "Internal error: ..\ztc\cgcs.c 213". If X is a union the problem remains, but not if it's a class.
>
> -----------------------
> Carlos Santander Bernal
>
>

On Fri, 20 Aug 2004 18:10:22 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:
> Well, I don't think it should crash, but one would presume bit is not allowed in struct or union types, since it has no
> meaning in C.
>
> If that's not the case, then it should be.

It was always my impression that structs were 'just' like C structs, not 'exactly' like C structs. What I mean is, they behave in the same ways, should be used for the same things, but, are not supposed to be identical in every way.

If a struct is simply a way to lay members out in memory, and members are simply accessed by an offset then why can't you have a bit in a struct, obviously if you had only one bit, there would be 7 wasted bits, or whatever was most efficient/convenient.

I don't see why allowing bits in D structs stops D from using existing C structs which won't have them.

Maybe I'm missing something.

Regan

> "Carlos Santander B." <carlos8294@msn.com> wrote in message news:cg41gm$2u2d$1@digitaldaemon.com...
>> Given the following code:
>>
>> /////////////////////
>> struct X
>> {
>>     bit flag;
>> }
>>
>> void main ()
>> {
>>     X x;
>>     x.flag = 0 != 0;
>> }
>>
>> /////////////////////
>>
>> dmd outputs: "Internal error: ..\ztc\cgcs.c 213". If X is a union the problem
>> remains, but not if it's a class.
>>
>> -----------------------
>> Carlos Santander Bernal
>>
>>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc06h1pg5a2sq9@digitalmars.com...
> On Fri, 20 Aug 2004 18:10:22 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:
> > Well, I don't think it should crash, but one would presume bit is not
> > allowed in struct or union types, since it has no
> > meaning in C.
> >
> > If that's not the case, then it should be.
>
> It was always my impression that structs were 'just' like C structs, not 'exactly' like C structs. What I mean is, they behave in the same ways, should be used for the same things, but, are not supposed to be identical in every way.
>
> If a struct is simply a way to lay members out in memory, and members are simply accessed by an offset then why can't you have a bit in a struct, obviously if you had only one bit, there would be 7 wasted bits, or whatever was most efficient/convenient.
>
> I don't see why allowing bits in D structs stops D from using existing C structs which won't have them.
>
> Maybe I'm missing something.

Because it would be unpleasantly inconsistent. D is already fragile in so far as one cannot include C headers into D source. If we then compound this disconnect by having not only different names for things, but having to match up bit variables in D with bitfields in C, it'll just be untenable.

I hope I'm right in thinking that structs and unions cannot contain bit types. If they are allowed, then that's just one more example of how ill/un-thought out this particular type is.

>
> Regan
>
> > "Carlos Santander B." <carlos8294@msn.com> wrote in message news:cg41gm$2u2d$1@digitaldaemon.com...
> >> Given the following code:
> >>
> >> /////////////////////
> >> struct X
> >> {
> >>     bit flag;
> >> }
> >>
> >> void main ()
> >> {
> >>     X x;
> >>     x.flag = 0 != 0;
> >> }
> >>
> >> /////////////////////
> >>
> >> dmd outputs: "Internal error: ..\ztc\cgcs.c 213". If X is a union the
> >> problem
> >> remains, but not if it's a class.
> >>
> >> -----------------------
> >> Carlos Santander Bernal
> >>
> >>
> >
> >
>
>
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
>
>Because it would be unpleasantly inconsistent. D is already fragile in so far as one cannot include C headers into D source. If we then compound this disconnect by having not only different names for things, but having to match up bit variables in D with bitfields in C, it'll just be untenable.

But D bit types are stored as bytes unless they're in an array, in which case they're arrays of packed bytes.  AFAIK this should dovetail quite well with the bool type in C/C++, which is typically stored in a byte as well.  Is this really much of a problem?


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:cg5dce$i1h$1@digitaldaemon.com...
> In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
> >
> >Because it would be unpleasantly inconsistent. D is already fragile in so far as one cannot include C headers into D source. If we then compound this disconnect by having not only different names for things, but having to match up bit variables in D with bitfields in C, it'll just be untenable.
>
> But D bit types are stored as bytes unless they're in an array, in which case they're arrays of packed bytes.  AFAIK this should dovetail quite well with the bool type in C/C++, which is typically stored in a byte as well.  Is this really much of a problem?

Asked and answered, old bean. Consider the poor hapless developer who needs to upgrade his struct from

C:

struct X
{
    bool    b;
    int        i;
};

D:

struct X
{
    bool    b;
    int        i;
}


to

struct X
{
    bool    b[2];
    int        i;
};

D:

struct X
{
    bool    b[2];
    int        i;
}

(Note: we're assuming pre-release modifications, of course. I'm not going to get into _that_ debate.)

Something tells me that this poor soul will be left with a pretty bad taste in his mouth!

In fact, there's an even nastier subtlety to this

Because the default packing of such a structure would have 3 pad bytes between the bool(s) and the int, and because D zero initialises, this might not be detected early, or at all!

On Fri, 20 Aug 2004 17:45:50 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
>>
>> Because it would be unpleasantly inconsistent. D is already fragile in so far as one cannot include C headers into D
>> source. If we then compound this disconnect by having not only different names for things, but having to match up bit
>> variables in D with bitfields in C, it'll just be untenable.
>
> But D bit types are stored as bytes unless they're in an array, in which case
> they're arrays of packed bytes.  AFAIK this should dovetail quite well with the
> bool type in C/C++, which is typically stored in a byte as well.  Is this really
> much of a problem?

Perhaps if Matthew gave an example of what he thinks is a problem we could discuss what we think is going on, Walter could tell us what actually is going on, and if we do indeed stumble across a problem, we can find a solution.

Here is what I have been playing with.. where am I going wrong.

import std.stdio;

extern(C)
{
  struct A {
    bool array[10];
  }
}

struct B {
  bit[10] array;
}

void main()
{
  bit[] p;
  A a;
  B b;

  a.array[1] = true;
  a.array[3] = true;
  a.array[5] = true;
  a.array[7] = true;
  a.array[9] = true;

  b.array[0] = true;
  b.array[2] = true;
  b.array[4] = true;
  b.array[6] = true;
  b.array[8] = true;

  p = a.array;
  printf("A: ");
  foreach(bit b; p)
  	printf("%d ",cast(int)b);
  printf("\n");

  printf("B: ");
  foreach(bit b; b.array)
    	printf("%d ",cast(int)b);
  printf("\n");

  b.array[] = cast(bit[])a.array;

  printf("B: ");
    foreach(bit b; b.array)
      	printf("%d ",cast(int)b);
  printf("\n");
}

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc14weyl5a2sq9@digitalmars.com...
> On Fri, 20 Aug 2004 17:45:50 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> > In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
> >>
> >> Because it would be unpleasantly inconsistent. D is already fragile in
> >> so far as one cannot include C headers into D
> >> source. If we then compound this disconnect by having not only
> >> different names for things, but having to match up bit
> >> variables in D with bitfields in C, it'll just be untenable.
> >
> > But D bit types are stored as bytes unless they're in an array, in which
> > case
> > they're arrays of packed bytes.  AFAIK this should dovetail quite well
> > with the
> > bool type in C/C++, which is typically stored in a byte as well.  Is
> > this really
> > much of a problem?
>
> Perhaps if Matthew gave an example of what he thinks is a problem we could discuss what we think is going on, Walter could tell us what actually is going on, and if we do indeed stumble across a problem, we can find a solution.

I did, old bean. About an hour ago.

Assuming that D does indeed pack arrays of bool/bit 8 to a byte, then my example is pretty clear.

Sorry I didn't see your reply before I posted Matthew... So what you're saying is, that is a developer has this

struct A {
  bool b[2];
  int  i;
}

in a C app, they re-write that app in D, using the same struct, the binary representation of that struct will not be the same as in the C app.

What about if they code their D as..

extern (C) {
  struct A {
    bool b[2];
    int i;
  }
}

will it look the same then? Doesn't the extern C above tell the D compiler to use the C padding rules etc.

Regan

On Sat, 21 Aug 2004 12:56:28 +1200, Regan Heath <regan@netwin.co.nz> wrote:

> On Fri, 20 Aug 2004 17:45:50 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
>> In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
>>>
>>> Because it would be unpleasantly inconsistent. D is already fragile in so far as one cannot include C headers into D
>>> source. If we then compound this disconnect by having not only different names for things, but having to match up bit
>>> variables in D with bitfields in C, it'll just be untenable.
>>
>> But D bit types are stored as bytes unless they're in an array, in which case
>> they're arrays of packed bytes.  AFAIK this should dovetail quite well with the
>> bool type in C/C++, which is typically stored in a byte as well.  Is this really
>> much of a problem?
>
> Perhaps if Matthew gave an example of what he thinks is a problem we could discuss what we think is going on, Walter could tell us what actually is going on, and if we do indeed stumble across a problem, we can find a solution.
>
> Here is what I have been playing with.. where am I going wrong.
>
> import std.stdio;
>
> extern(C)
> {
>    struct A {
>      bool array[10];
>    }
> }
>
> struct B {
>    bit[10] array;
> }
>
> void main()
> {
>    bit[] p;
>    A a;
>    B b;
>
>    a.array[1] = true;
>    a.array[3] = true;
>    a.array[5] = true;
>    a.array[7] = true;
>    a.array[9] = true;
>
>    b.array[0] = true;
>    b.array[2] = true;
>    b.array[4] = true;
>    b.array[6] = true;
>    b.array[8] = true;
>
>    p = a.array;
>    printf("A: ");
>    foreach(bit b; p)
>    	printf("%d ",cast(int)b);
>    printf("\n");
>
>    printf("B: ");
>    foreach(bit b; b.array)
>      	printf("%d ",cast(int)b);
>    printf("\n");
>
>    b.array[] = cast(bit[])a.array;
>
>    printf("B: ");
>      foreach(bit b; b.array)
>        	printf("%d ",cast(int)b);
>    printf("\n");
> }
>
> Regan
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Sat, 21 Aug 2004 11:03:23 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:

> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc14weyl5a2sq9@digitalmars.com...
>> On Fri, 20 Aug 2004 17:45:50 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
>> > In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
>> >>
>> >> Because it would be unpleasantly inconsistent. D is already fragile 
>> in
>> >> so far as one cannot include C headers into D
>> >> source. If we then compound this disconnect by having not only
>> >> different names for things, but having to match up bit
>> >> variables in D with bitfields in C, it'll just be untenable.
>> >
>> > But D bit types are stored as bytes unless they're in an array, in 
>> which
>> > case
>> > they're arrays of packed bytes.  AFAIK this should dovetail quite well
>> > with the
>> > bool type in C/C++, which is typically stored in a byte as well.  Is
>> > this really
>> > much of a problem?
>>
>> Perhaps if Matthew gave an example of what he thinks is a problem we could
>> discuss what we think is going on, Walter could tell us what actually is
>> going on, and if we do indeed stumble across a problem, we can find a
>> solution.
>
> I did, old bean. About an hour ago.

I know, my eyes must be broken.

> Assuming that D does indeed pack arrays of bool/bit 8 to a byte, then my example is pretty clear.

I might still be a bit fuzzy on it.. It's the structures binary layout you're concerned with right? Doesn't D have some struct padding specifiers? Does extern C change the way it pads structs?

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/