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
