No subject

Tue Jul 12 12:13:23 PDT 2011

hinge went down and as a result I went stand still and today finally it got=
 repaired so I posting mails now<br><br>Before:- <a href=3D"https://plus.go=">htt=

After:- <a href=3D"
84985253/albums/posts/5628545749910118610</a><br><br><div class=3D"gmail_qu=

On Tue, Jul 5, 2011 at 12:18 AM, Jamey Sharp <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jamey at">jamey at</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex;">

<div class=3D"im">On Mon, Jul 04, 2011 at 03:42:24AM +0530, vikash agrawal =
&gt; Also it has been long I am trying to patch a bug, I had several discus=
&gt; with pharris ( I apologise for pestering you so much ) over the same. =
I am<br>
&gt; still studying and a quick glance of it reveals<br>
&gt; &#39;_c_serialize_helper_insert_ =A0function&#39;, with context being =
sizeof, is<br>
&gt; responsible for xcb_str_sizeof in xproto.c. So I believe this might ne=
&gt; some hacks.<br>
&gt; Also, if I am not wrong there is a problem with xcb_str_next with resp=
&gt; master and 1.7, but for this I have a very n00b and basic idea like if=
&gt; self.c_next_name =3D=3D &#39;xcb_str_next&#39;: # and then necessary c=
onditions of<br>
&gt; _c(&#39;whatever&#39;); might solve the purpose. If this feels a way t=
hen can we<br>
&gt; specifically do the same for other buggy issues.<br>
</div>I&#39;m sorry to say, the problem is not specific to xcb_str_next or =
strings at all. The good news is that it should be solvable in a general<br=
way, without hacks for specific types. I wrote some about this here:<br>
<a href=3D"
" target=3D"_blank">
Here is a sketch of an algorithm that I believe is correct for<br>
statically computing alignment padding for all X types. I&#39;ll use the<br=
terms from xcbgen/<br>
First, compute the minimum alignment requirement for every type:<br>
- For every SimpleType and ExprType, including the standard types like<br>
 =A0CARD8, the alignment required equals the size of the type, but no more<=
 =A0than 4 bytes. So CARD8 needs 1 byte, INT16 needs 2 bytes, FLOAT needs<b=
 =A04 bytes, and DOUBLE also needs 4 bytes.<br>
- For ListTypes, the alignment is the same as the member type&#39;s<br>
- Request, Reply, Event, and Error types always have 4-byte alignment.<br>
- For StructType and UnionType, the alignment is the maximum alignment<br>
 =A0needed by any field in the struct or union. So STR, which is a struct<b=
 =A0containing a CARD8 and a list of CARD8, only needs 1-byte alignment;<br=
 =A0but a struct containing an INT16 and a DOUBLE needs 4-byte alignment.<b=
I haven&#39;t thought about the rules for Switch or Bitcase yet.<br>
I think implementing the above in proto/xcbgen would be a good target<br>
for something to finish by the time of the mid-term review. The rest of<br>
the algorithm is below.<br></blockquote><div><br>I think I have successfull=
y completed till here<br>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;">

Once you know the alignment of every type, you can insert correct<br>
padding. Only ComplexTypes actually insert padding anywhere.<br></blockquot=
e><div><br>This will require a hack in which source file? ?<br>=
[ Before I have thought to write the code in a separate file but couldn&#39=
;t get any idea on how do I test it ]<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.=
8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
You need to keep track of the byte offset of every field in a complex<br>
type, modulo 4. The first field in a complex type is at offset 0.<br></bloc=
kquote><div><br>How will I know when a type is being instantiated? and what=
 is its size?<br>As it will needed to for me to track offset <br>Technicall=
y I plan to use dictionary, with :-<br>

<br>&#39;&lt;name or type &gt;&#39; =3D [ &lt;offset_before_padding&gt;, &l=
t;offset_after_adding_size&gt;, &lt;final_offset&gt;, &lt;offset_of_next_el=
ement&gt; ] <br><br><a href=3D"

<br>and may be, I will use linked list but I am not sure for the LL at this=
 point of time<br>but I not able to understand where do I bring this hack t=
o get most of it and I am sure I will have 4-5 errors wrt module.resole() a=
nd etc so how do I cater that<br>

<br>Also can there e a better way for the above<br>=A0<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px=
 solid rgb(204, 204, 204); padding-left: 1ex;">
For each field you add, first check whether its alignment requirements<br>
are met, and if not, insert padding. So if you try to add a CARD16,<br>
which has 2-byte alignment, at offset 1, then you need 1 byte of<br>
padding. To add a CARD32, needing 4-byte alignment, at offset 1, you<br>
need 3 bytes of padding.<br>
Once you&#39;ve added any needed padding, add the field itself. Then the ne=
byte offset is the old offset, plus the padding, plus the size of the<br>
field, mod 4.<br>
After you&#39;ve added all the fields, insert final padding for the<br>
alignment of the ComplexType itself. If this was a struct that had a<br>
CARD32 field in it, or it was a Request/Reply/Event/Error, then you need<br=
to make sure the final byte offset, mod 4, is 0. If its maximum<br>
alignment was 2, then the final byte offset mod 2 must be 0. This<br>
ensures that a list of values of this type has correct padding between<br>
the members.<br>
The spot where this is a little difficult is if the complex type<br>
contains a list or a variable-length structure. The easy case is when a<br>
field has 4-byte alignment: Then you know that no matter what its length<br=
turns out to be, afterward the byte offset (mod 4) is always 0.<br>
Otherwise, the byte offset after adding the field is not a constant, but<br=
a (potentially complicated) expression. For example, if the field is a<br>
list of fixed-size members, then you need to add sizeof(member) times<br>
the list&#39;s expression. You&#39;ll eventually emit these complicated byt=
offset expressions into the generated C code, when inserting padding for<br=
some following field.<br>
At that point I think the bug will be fixed, and we&#39;ll be quite pleased=
with your Summer of Code project. :-) But there&#39;s one more improvement:=
Since we only care about the byte offset mod 4, many complicated byte<br>
offset expressions can be simplified. For example, if there are two<br>
lists of CARD16s in a row that both use the same length expression, then<br=
you might construct this byte offset expression:<br>
 =A0 =A0 =A0 =A0old_offset + ((2 * length) + (2 * length)) % 4<br>
But that turns out to just equal &quot;old_offset&quot;, because (4 * x) % =
4 =3D=3D 0<br>
for all x. This is a generalization of the above case where fields with<br>
4-byte alignment always result in a byte offset of 0.<br>
I hope that helps!<br>
<font color=3D"#888888">Jamey<br>
</font></blockquote></div><br>Love<br><br>Vikash Agrawal<br>


More information about the Xcb mailing list