Make useconds_t a concrete, unsigned type. Add suseconds_t.

[toots]

I'm not sure why useconds_t was originally marked as abstract and not exported with concrete type. The posix specification is clear about it:

The type useconds_t shall be an unsigned integer type capable of storing values at least in the range [0, 1000000].

I'm also adding suseconds_t while at it. Its specification is also clear:

The type suseconds_t shall be a signed integer type capable of storing values at least in the range [-1, 1000000].

Source: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/types.h.html

I'm planning on using these for https://github.com/toots/ocaml-posix-time

[toots]

@yallop Any feedback on this? We would need it merged to add this functionality to liquidsoap: savonet/liquidsoap#1050. We can expose these data types in https://github.com/toots/ocaml-posix-time if needed otherwise.

[toots]

Another, perhaps better approach, would be to take the whole PosixTypes out of this module so as to untie its releases from the main module's. Happy to work on this if y'all think it's a good idea.

[yallop]

The Appveyor build is failing because suseconds_t is not available on Windows (which is why it was removed in #190 / 92894a5).

Do you definitely need suseconds_t, or would it be possible to focus on improving the interface to useconds_t?

[toots]

Ha, I see, thanks for the explanation @yallop. Yeah, it's the data type used in https://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/time.h.html to bind some common functions that I would like to export such as gettimeofday.

In this case, what do you think of taking PosixTypes out of ctypes entirely? That would make ctypes more flexible to build on both windows and unix systems and, on the other hand, we could build a consolidated repository for all posix-related bindings using ctypes, with windows APIs whenever appropriate like I've done here:https://github.com/toots/ocaml-sys-socket

[yallop]

In this case, what do you think of taking PosixTypes out of ctypes entirely?

I think it's a good idea (although I think it's best to deprecate it first, rather than take it out straightaway). Actually, the posix-types package is already a start in that direction; I'm not sure offhand how it compares to the PosixTypes module here, though.

we could build a consolidated repository for all posix-related bindings using ctypes

That sounds very useful. As I think you know, @dsheets has quite a few of these: unix-errno, unix-fcntl, unix-sys-resource, unix-sys-stat, unix-time, and several osx-specific libraries, too. (You might also find it interesting to look at how those libraries use Lwt to build non-blocking bindings, e.g. for Fcntl.open.)

[toots]

Awesome! Yes, of course deprecating first is good although with opam these days it's easier to version dependencies and break things.

I didn't know about posix-types module, great starting point and, yes, I use already use @dsheets's modules in my own, which is also what gave me the idea to consolidate all these projects.

Lastly, when working on sys-socket, I came up with a scaffolding structure using dune and ctypes (described here) that I believe allows for very elegant and reusable patterns to quickly bind types and structures and I'd like to also explore having all the projects using a common, lean framework.

I'll work on a proposal then and will come back to y'all soon. Thanks!

[toots]

Ok, here's a proposal: https://github.com/savonet/ocaml-posix

The repositry has:

• The existing PosixTypes with some minor changes (add Arithmetic API for arithmetic types, unified some integer types with no sign specified to be unsigned). It's still missing some of the opaque types.
• posix-socket and posix-time adapted to use types from the new posix_types.
• A unified, single repository for all module so they can:
  • Depend on each other at build
  • Be released separately if needed

I think it looks pretty exciting. What do y'all think of it @yallop and @dsheets ? Ultimately, I'd like to bring all the various posix-related modules under that umbrella.

[toots]

Actually, sigset_t isn't part of <sys/types.h>, contrary to the doc. Any reason it was added to PosixTypes?