Ah, good point on alignment and padding... So the take home message is: Don't do that. thx MS
Philip Levis wrote: > On Apr 13, 2010, at 8:52 AM, Michael Schippling wrote: > >> There's a couple things going on in your example... >> >> First, my belief based on not using or having looked very deeply >> into nx_ types, is that they are byte reversed -- nx_int16 is the >> big-endian version of the usual suspect which is little-endian on >> all the platforms we commonly use. However I don't know where the >> byte reversal occurs, if it's in the message transmit code then >> some of the following probably doesn't pertain. > > On every access. Take a look at the generated C. > >> Second, the "typeA x = (typeA) y;" code is actually a structure >> assignment, not just a cast, so it would try to copy the contents >> of y into x. I think this will work on any two structs, but it >> might be size dependent. Your two structs are probably the same >> size so you might not have an issue. However, depending on where >> the byte-reversal takes place, you might end up with reversed >> integer values in x after the copy if you have anything other than >> single byte objects in the struct -- you should slip by given the >> two definitions you show here though. > > > >> If your code was this it would be a simple cast: typeA *x = >> (typeA) &y; I think you would have no complaints from the C >> compiler, unless something in NESCC traps nx_ conversions. You >> might still have the byte reversal issues though. >> > > This would be a bad idea, as nx types also affect alignment. Just > because the structures have fields with the same names doesn't really > help nesC; it can't assume that the fields correspond. The correct > thing to do is just copy each field individually: > > y.a = x.a; y.b = x.b; y.c = x.c; > > Phil > > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
