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
