Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make useconds_t a concrete, unsigned type. Add suseconds_t. #620

Closed
wants to merge 1 commit into from

Conversation

@toots
Copy link

toots commented Dec 15, 2019

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

This comment has been minimized.

Copy link
Author

toots commented Dec 15, 2019

@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

This comment has been minimized.

Copy link
Author

toots commented Dec 15, 2019

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

This comment has been minimized.

Copy link
Member

yallop commented Dec 16, 2019

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

This comment has been minimized.

Copy link
Author

toots commented Dec 16, 2019

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

This comment has been minimized.

Copy link
Member

yallop commented Dec 16, 2019

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

This comment has been minimized.

Copy link
Author

toots commented Dec 16, 2019

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

This comment has been minimized.

Copy link
Author

toots commented Dec 27, 2019

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

This comment has been minimized.

Copy link
Author

toots commented Dec 27, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.