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

[Harald Kipp]

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.

For good reasons, see below.


> There are some traps with using this rule:
> You need to limit the maximum byte count to a value that guarantees to
> be less then the negative roll over value caused by bit-width of your
> return variable. For ARM 32 bits and Cortex 16 bits are fine as you
> will not send a block of more than 32767 bytes through I2C in one
> transfer. But with 8 bit platforms you need to declare return values
> as int (preciesly int16_t) or limit transfer to 127 bytes in one
> transfer.

I cannot follow. What I understood is:

Per C standard, an int is defined as the "natural size" of the target,
but not less than 16 bits. When checking for positive or negative
results only, returning an int will allow 32k-1 on 8-bit and 2G-1 on
32-bit targets. In other words, half of the available address space. I
never had any problems with this limitation.

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.

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.

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?

Regards,

Harald