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

My personal branch of this library #5

Open
promovicz opened this issue Nov 14, 2021 · 5 comments
Open

My personal branch of this library #5

promovicz opened this issue Nov 14, 2021 · 5 comments

Comments

@promovicz
Copy link
Contributor

Hello!

I would just like to inform you that I have inadvertently forked your library.

My version has by now diverged significantly, but maybe you can find something useful in the commit history. You can find my working branch here https://github.com/promovicz/timespec.

Some of my recent commits have fixed rounding bugs, some of which are related to issue #4. My version of the library also has a compatibility layer for an old Solaris utility header. Some of it even has tests. In fact the test vectors/values might be worth reviewing and adjusting with regards to #4.

Best Regards
prom

@solemnwarning
Copy link
Owner

Thanks for raising this, I'll be sure to go through your changes properly and integrate them as appropriate when I've got the time!

@ian-abbott
Copy link

In both forks, timespec_from_double has Y2038 problems on platforms with 32-bit long. Maybe use .tv_nsec = (s - (time_t)(s)) * NSEC_PER_SEC, to fix it?

I can raise that as a separate issue for this repo, but @promovicz's fork doesn't have issue reporting set up.

@solemnwarning
Copy link
Owner

solemnwarning commented Dec 1, 2021

@promovicz I've noticed your fork has "fast" versions of some functions, which appear to just be inlined from the header rather than compiled into their own module?

Did you find the performance improvement of this worthwhile in your application?

EDIT: Just realised they also skip normalisation, but question stands

@promovicz
Copy link
Contributor Author

The point of the fast versions is to skip normalization when you know that you don't have to normalize. I've done this because of systematics and not because of need, but it is a low-hanging fruit because the inline versions of those functions are really tiny and worth inlining.

BTW it's actually possible to compile the test down to "return 0". that's how much the optimizer can do to those functions.

@promovicz
Copy link
Contributor Author

@ian-abbott I've turned on issues on my repo, but I don't really want the extra maintenance load. :)

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

No branches or pull requests

3 participants