[M3devel] zero sized structs?

[Jay K]

Yes..the assertions all passes..but granted, maybe we don't have full coverage. I can look at the frontend, or just make it so in the backend.

On further thought..by quick read..this M3x86.m3 code is questionable.While in_proc is usually false for declare_local, I think it really goes both ways.So it looks like size is sometimes rounded up to 4, sometimes left as zero.

But what does it mean?Does a zero sized array get any storage?In C and C++, two objects can't be at the same address, so, for example:struct foo { } bar; is not legal C. It is legal C++, however:

struct foo { } a,b;assert(&a != &b); will pass.

andvoid* a = malloc(0);void* b = malloc(0);assert(a != b) will also pass in C and C++.

That is, size 0 struct is invalid in C. In C++ it is rounded up to at least 1.malloc(0) is rounded up to at least 1.No two "objects" can have the same address.

What is the meaning Modula-3?Rounding up to 1 or alignment seems easy/decent.Certainly these zero sized things are rare in our tree.

 - Jay



CC: m3devel at elegosoft.com
From: antony.hosking at gmail.com
Subject: Re: [M3devel] zero sized structs?
Date: Thu, 4 Oct 2012 09:21:28 -0400
To: jay.krell at cornell.edu

Try to respect alignment. 

Sent from my iPad
On Oct 4, 2012, at 2:25 AM, Jay K <jay.krell at cornell.edu> wrote:





	declare_local	 noArgs 0 8 Struct -1522787086 T F 50 v.318

and here is some relevant M3x86 code:
    IF u.in_proc THEN      v := get_temp_var (u, type, s, a, n);    ELSE      v := create_temp_var (u, type, s, a, n);    END;

PROCEDURE get_temp_var (u: U; type: Type; s: ByteSize; a: Alignment;                        n: Name := M3ID.NoID): x86Var =  BEGIN
    (* round size and alignment up to 4 *)
    IF s < 4 THEN      s := 4;    END;
    IF a < 4 THEN      a := 4;    END;

PROCEDURE create_temp_var (u: U; type: Type; s: ByteSize; a: Alignment;                           n: Name): x86Var =  VAR v := NewVar(u, type, 0, s, a, n);  BEGIN    v.loc := VLoc.temp;    v.parent := u.current_proc;
    u.current_proc.framesize := Word.And(u.current_proc.framesize + a - 1,                                         Alignmask[a]);
    INC(u.current_proc.framesize, s);
    v.offset := -u.current_proc.framesize;
    RETURN v;  END create_temp_var;

which isn't clear by inspection...it actually looks likezero size is allowed through commonly...in_proc is rare,so create is common...assuming the frame is already aligned,the size remains unchanged...

Relevant aside: I have been ignoring alignment.I'm inclined to go with something like:
<* ASSERT (size MOD alignment) = 0 *>

If that ever fails, then I will change it to:

FUNCTION RoundUp(a, b: INTEGER): INTEGER =BEGIN  WITH c = a MOD b DO    IF c # 0 THEN      RETURN a + b - c;    END;  END;  RETURN a;END;
size := RoundUp(size, alignment);

and then, more to the point, I'll go with:
IF size = 0 THEN  size = 1;END;

I haven't dug into what the gcc backend would do here, too muchto dig through. :)

Thoughts?

I guess I should try both m3x86 and m3cc, and print the addressof these things????

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Thu, 4 Oct 2012 06:13:28 +0000
Subject: [M3devel] zero sized structs?




Building obliqrt I get:

****** runtime error:***    <*ASSERT*> failed.***    file "../src/M3C.m3", line 1768***


PROCEDURE GetStructSizes_Declare(self: GetStructSizes_t; type: Type; byte_size: ByteSize): M3CG.Var =BEGIN    IF type = Type.Struct THEN        <* ASSERT byte_size > 0 *>        self.sizes[self.count] := byte_size;        INC(self.count);    END;    RETURN NIL;END GetStructSizes_Declare;

due to presumably:

PROCEDURE ApplyThreadClosure (self: ObliqThreadClosure): REFANY =  VAR noArgs: ARRAY [0 .. -1] OF ObValue.Val;

...
PROCEDURE HandleWork (self: ObliqWork) =  VAR noArgs: ARRAY [0 .. -1] OF ObValue.Val;
..PROCEDURE EvalThread (                    self  : PackageThread;...noArgs    : ARRAY [0 .. -1] OF ObValue.Val;

What is the meaning of this?

 - Jay

 		 	   		   		 	   		  
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121004/719e20ef/attachment-0002.html>