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
*
*
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
