[En-Nut-Discussion] RFC: Changing Nut/OS device API to use size_t as type for length parameters in read() and write() and similar functions

[Harald Kipp]

Hi Ole,

On 29.09.2015 23:55, Ole Reinhardt wrote:
> while debugging the bug mentioned in my last posting, I realised, that
> our device API, the libc implementation and the driver implementations
> do not use consistent variable types for length parameters and return
> values.

Yes.


> For our platform, this might be more a theoretical problem, but I would
> suggest to harmonize the usage of integer types through the APIs.

Frankly, I never came to any consistent conclusion. The problem is, that
the "signed" ssize_t is not always available and some functions need to
be able to return -1, while size_t is typically unsigned and cannot
become -1.


> For example:
> 
> _write() is defined as
> 
> int _write(int fd, const void *data, size_t count)
> 
> similar for read()
> 
> 
> fwrite() is defined as
> 
> size_t fwrite(const void *data, size_t size, size_t count, FILE * stream)

That's correct, because _write needs to be able to return -1, while
fwrite always returns positive values only.

> I'd like to suggest to follow POSIX and
> 
> a)
> use size_t for all length / size parameters and internal calculations
> based on these values
> 
> b)
> use ssize_t or size_t as return value for functions that return sizes
> (of read or written data for example)

Yes, this is the correct Posix way.

Regards,

Harald