[Tinyos-devel] ENOMEM in TinyError.h

[Kevin Klues]

I like ENORESOURCE, and I think it should be added.

Kevin

On Tue, May 20, 2008 at 12:59 PM, Matt Welsh <mdw at eecs.harvard.edu> wrote:
> 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
>>
>>
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>



-- 
~Kevin