[Tinyos-devel] ENOMEM in TinyError.h

[Matt Welsh]

Maybe we got sidetracked here, but do I understand that it's OK for us  
to add either ENOMEM or ENORESOURCE to TinyError.h? (I agree we need  
custom error codes too, but this is one that is likely to be useful  
across many components.)


On May 13, 2008, at 2:46 PM, David Moss wrote:
> 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
>
>