[Tinyos-devel] Limiting typedef parameters of generic modules to non-struct types

[Kevin Klues]

I recently came across a problem with using the QueueC component to
define a queue of size greater than 256.  The problem has to do with
limitations of the nesC syntax, and not of the component
implementation itself.

As it stands now, the QueueC component is defined as

generic module QueueC(typedef queue_t, uint8_t QUEUE_SIZE) {
  provides interface Queue<queue_t>;
}

and then its implementation has variables to manage the queue defined
as follows:
  uint8_t head = 0;
  uint8_t tail = 0;
  uint8_t size = 0;

If I want to create a queue that can hold, say, 500 elements, I have
to make a copy of the QueueC component, change its definition to
contain a QUEUE_SIZE variable that is of type uint16_t,  modify head,
tail, and size to be uint16_t's as well,  and change the Queue
interface to have the return types for Queue.size() and
Queue.maxSize() be uint16_t.  All of the logic in the actual QueueC
implementation remains unchanged.

One thought I had to get around this was to add another parameter to
the definition of QueueC that would allow me to specify the type that
should be associated with head, tail, and size, and then just set
QUEUE_SIZE to be of type uint32_t.  Since QUEUE_SIZE is a constant and
it isn't feasible that you would ever have a queue size of 2^32 or
greater, choosing this width seemed reasonable.

generic module QueueC(typedef queue_t, typedef queue_size_t, uint32_t
QUEUE_SIZE) {
  provides interface Queue<queue_t, queue_size_t>;
}

The problem with this is that I can't just do something like the
following in the implementation of QueueC anymore:
  queue_size_t head = 0;
  queue_size_t tail = 0;
  queue_size_t size = 0;

The reason is that nesC believes that queue_size_t could be any type
including a struct, and assignment of a struct can't be done in the
way shown.  I would need a way of telling nesC that I am limiting
queue_size_t to non-struct types (i.e. uint8_t, uint16_t, and
uint32_t) so that it would not throw an error when assigning a
variable of that type to a number.

Can anyone think of a nice, elegant way to deal with this?  Or is the
best solution to just create separate Queue8C, Queue16C and Queue32C
components that only differ in the maximum size their queues can be.
Seems like unneeded duplication of code to me though....

-- 
~Kevin