Hi all,
When doing my continuous builds of Rust, I noticed that our
definitions for readv() and writev() do not follow the IEEE Std
1003.1-2001 spec [1].
Our function declarations are:
ssize_t readv(int fd, const struct iovec *vector, size_t count);
ssize_t writev(int fd, const struct iovec *vector, size_t count);
According to the standard, the third argument should be an int instead
of a size_t. It seems that the size_t type is a design choice that
comes from when Be introduced readv(), writev() and the (non-standard)
readv_pos() and writev_pos() functions [2], which probably preceeded
the standard.
Now by itself the choice for size_t makes sense, since you cannot have
a vector with negative elements. However, it deviates from the
standard and that trips up languages that are a bit more explicit
about their type-adherence (like Rust).
Fixing the definition is not without issues:
* There are differences in signedness (size_t is unsigned, and int is signed).
* On x86_64, there is also a difference in size (size_t is 64 bit/8
bytes, int is 32 bit/4 bytes).
* Internally, readv and writev have further hooks down the system,
including in the kernel and the boot menu.
I am not sure whether changing from unsigned to signed constitutes an
ABI change on x86, but I think the size change on x86_64 will for sure
break the ABI.
I have published a WIP patch on Gerrit:
https://review.haiku-os.org/c/haiku/+/3770
I am looking for some input on whether we have any interest on getting
these changes in, and if so, whether the current change is acceptable.
Or whether it is better to go for the alternative, which is to work
around it in Rust.
Regards!
N>
[1] https://pubs.opengroup.org/onlinepubs/009695399/functions/readv.html
and https://pubs.opengroup.org/onlinepubs/009695399/functions/writev.html
[2]
http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/aboutbe/benewsletter/volume_II/Issue36.html
and
http://testou.free.fr/www.beatjapan.org/mirror/www.be.com/aboutbe/benewsletter/volume_II/Issue35.html
