Hello,
This is a heads-up for people who are using skalibs, or any of the
libraries in the skarnet.org projects (which are undergoing the same
transformation).
Since the beginning, skalibs has used ints and unsigned ints about
everywhere in its prototypes. This is legacy from DJB, and comes from a
time where POSIX compliance was dubious on a lot of systems. (It still
is, but divergences between POSIX and development environments are a
lot more subtle today than they were 15 or 20 years ago.)
Use of integer types rather than POSIX types was the reasonable thing
to do back then; but for a few years, it has not been necessary and has
become a drawback and a concern rather than an advantage. For instance,
on x86_64, skalibs does not support IO on more than 2 GB at a time.
This is going to change soon (probably towards the end of February, or
in March). skalibs prototypes will now use POSIX types - such as size_t
and ssize_t instead of unsigned int and int, struct iovec instead of
siovec_t, uint32_t instead of uint32, etc. (You can still keep using
uint16/uint32/uint64 for a few versions.)
You can prepare your software right now in your applications by
already changing your types. That's what all the applicative skarnet.org
packages do in the recent commits. For instance, instead of
unsigned int max = MAX ;
int r = fd_read(fd, buf, MAX) ;
you'd write:
size_t max = MAX ;
ssize_t r = fd_read(fd, buf, MAX) ;
(Remember to include <sys/types.h> and <stdint.h> as needed.)
so the limiting factor is skalibs and not your application, and your
application becomes 64-bit-ready when skalibs changes.
Of course, those changes are the easy part. The hard part is if you
have pointers. You can't replace "unsigned int *" with "size_t *" and
be compatible with the old skalibs. I advise you to mark those places
in your code with a comment, so you can quickly adapt to the new skalibs
API when it comes out.
Thanks for your understanding.
--
Laurent
Received on Mon Jan 30 2017 - 17:19:38 UTC