[En-Nut-Discussion] Returning ints (was Missing possibility in the I2CBUS API)
ulrich.prinz at googlemail.com
Wed May 15 18:09:11 CEST 2013
2013/5/7 Harald Kipp <harald.kipp at egnite.de>:
> Hi Ulrich,
> To stop this threadjacking, I'm opening a new topic.
> On 06.05.2013 14:00, Ulrich Prinz wrote:
>> In many cases NutOS just returns -1 in case of error and then leaves
>> it to the user to find the right variables to query for detailed error
If I reorder your Answer it might show you what I meant:
> Per C standard, an int is defined as the "natural size" of the target,
> but not less than 16 bits.
> Therefore, returning an 8-bit value on 8-bit targets doesn't save any
> code. Furthermore, returning less bits than an int will often add more
> code to targets with larger word sizes, because any upper bytes of the
> result need to be cleared.
Ok, forcing usage of at least 16 bit on an 8-bit architecture doesn't
introduce code overhead...
Wasn't it like AVR has lots of 8-bit registers but only two pairs of
them are supported for beeing combined as two 16-bit registers.
> External C function never return less than an int. This is required,
> because functions may be called without explicitly defining a prototype,
> in which case an int is assumed.
Using external C functions without proper header file and accepting
compiler warnings is bad coding style and I do not like to support
that in any way.
> My conclusion is: Returning an int will naturally fit 90% of the all
> functions. However, throughout Nut/OS development lifetime I'm
> discovering newly added external functions defining smaller return
> values than an int.
> Do I miss something?
No, your answer is right for me as it meet 100% of the architectures I use.
Who cares about AVR if you can use ARM with more power and memory for
the same price...
More information about the En-Nut-Discussion