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
