I'll look into it in a week or so... David On Feb 12, 2013 7:14 PM, "Eric Decker" <[email protected]> wrote:
> > > Sigh. Would of been nice if we could have found a work around. > > File it as a bug against https://github.com/tinyos/nesc > > Maybe we can get David's attention. David? > > On Tue, Feb 12, 2013 at 3:48 AM, Johny Mattsson <[email protected]>wrote: > >> On 12 February 2013 13:31, Eric Decker <[email protected]> wrote: >> >>> First, the #define works because it is simple text substitution. So if >>> you look at the resultant app.c you will see >>> >>> error_t foo(nx_uint16_t val) >>> >>> when using the define. >>> >>> So of course it works. >>> >> >> I'd like to think so, but given that a plain typedef doesn't work in this >> situation, I wouldn't say "of course" - there could've been something wrong >> with using nx types as pass-by-value parameters, for example. :) >> >> >> If you compile Blink say for the telosb and then take a look at app.c you >>> can see where the nx types are defined. Search for nx_uint16. >>> >> >> I'll do you one better, I'll show you what's in the app.c from the >> minimal test case in my previous email: >> >> First there's the nx_uint16_t which is an innocuous enough packed struct: >> typedef struct { unsigned char nxdata[2]; } __attribute__((packed)) >> nx_uint16_t; >> >> Then there's an unused typedef of a __nesc_nxbase_nx_uint16_t whose use >> I'm not entirely clear on without delving into compiler internals: >> typedef uint16_t __nesc_nxbase_nx_uint16_t ; >> >> There is of course my typedef, looking as expected (module__type name): >> typedef nx_uint16_t TestNxTypedefP__my_type16_t; >> >> And then there's the weirdness of the function taking my typedef'd type >> as an argument: >> static inline error_t >> TestNxTypedefP__foo(TestNxTypedefP____nesc_nxbase_my_type16_t val); >> >> What I had expected to see here was: >> static inline error_t TestNxTypedefP__foo(TestNxTypedefP__my_type16_t >> val); >> >> >> It seems the compiler has an internal translation rule for nx types that >> translates them from the struct version to the "base" version. When >> compiling with the #define rather than the typedef, the function prototype >> looks like this: >> static inline error_t TestNxTypedefP__foo(__nesc_nxbase_nx_uint16_t >> val); >> >> >> To me this seems like a nesc issue (or at the very least a nesc >> documentation issue). >> Who/where do I bounce this to? Running nescc --help only points at the >> gcc bug reporting, which is clearly not applicable here. >> >> >> >>> Maybe adding a nx_ prefix to your type would help. >>> >> >> Tried that, it didn't help. >> >> >> Thanks, >> /Johny >> * >> * > > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
