Skip to content

Fix passing timezone structure in Tsettimeofday()/Tgettimeofday() #15

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

Closed
wants to merge 1 commit into from

Conversation

th-otto
Copy link
Contributor

@th-otto th-otto commented Jul 9, 2017

No description provided.

@atic-atac
Copy link
Contributor

Why this patch, mintlib is only ever compiled for 32bit now, so ints are 32bit.

@th-otto
Copy link
Contributor Author

th-otto commented Jul 10, 2017

mintlib is only ever compiled for 32bit now, so ints are 32bit.

Maybe currently. But i think this is an unnecessary restriction. Gem programs like toswin2 and teradesk would be much more efficient if they could be compiled with -mshort. And in any case, long and int are different things, only because they happen to be the same size does not make them identical.

@atic-atac
Copy link
Contributor

atic-atac commented Jul 10, 2017

mintlib isn't compiled for mshort because of catching issues such as this. So toswin2/teradesk shouldn't be compiled against mintlib with mshort because it definitely will not work, even with this small fix. There are many many many more of these around. That's pretty much why Frank and the folks working on mintlib abandoned anything but 32bit.

@th-otto
Copy link
Contributor Author

th-otto commented Jul 10, 2017

There are many many many more of these around.

Yes, i'm aware of that. Not really many, but quite a few. Of course those issues should be fixed, too.

@atic-atac
Copy link
Contributor

So, I don't think your patch is the right then, it should change the original structure and not create a new one. Also if you want to support non-32bit mintlibs then the patch should be extensive and cover the entire library.

So feel free to carry on on your own branch until a much fuller fix is available, but I don't see any point in merging this to master.

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

Successfully merging this pull request may close these issues.

3 participants