[Tinyos-devel] ENOMEM in TinyError.h

[David Moss]

I was actually referring to Miklos's comment:

"Are we sure that every interface returns only those error codes that are
actually documented?"

If an error code is being passed back that isn't documented (i.e. it isn't
in the tinyos baseline) then it must be some custom error code, right?


If people are using custom error codes (I've thought about it before but
haven't done it), then the unique() thing you brought up would be a nice way
to go, IMHO.

-David



-----Original Message-----
From: Philip Levis [mailto:pal at cs.stanford.edu] 
Sent: Tuesday, May 13, 2008 11:31 AM
To: David Moss
Cc: 'Matt Welsh'; 'TinyOS-Devel list'; 'Miklos Maroti'
Subject: Re: [Tinyos-devel] ENOMEM in TinyError.h


On May 8, 2008, at 8:45 AM, David Moss wrote:
>
>
> Undocumented error codes are defined in custom applications.  Can we  
> suggest
> end users define error codes above 128 to avoid conflict with an 
> evolving
> TinyOS baseline?

Is the issue that components want to use the current error_t values  
but add new ones? One could always define a new app_error_t. Or is it  
that you want to use standard interfaces?

One approach is to define some content-free names for specific error  
codes, such as ECUSTOM1, ECUSTOM2, ECUSTOM3. Another is to define an  
ELAST, which is the last value+1, and allow systems to extend the set  
with unique() + ELAST. I think error codes are a slightly different  
beast than AM IDs, in that there aren't the same kind of  
interoperability issues.

Phil