[En-Nut-Discussion] Returning ints (was Missing possibility in the I2CBUS API)

[Ulrich Prinz]

Hi Harald

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
>> information.
>

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...

Regards
Ulrich