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

gh-92869: ctypes: Add c_time_t #92870

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

gh-92869: ctypes: Add c_time_t #92870

wants to merge 9 commits into from

Conversation

thp
Copy link
Contributor

@thp thp commented May 17, 2022

This implements a simple way of using ctypes.c_time_t for 32-bit and 64-bit time_t sizes. See #92869 for a discussion on why this is useful and considerations for different platforms. This doesn't take into account platforms where time_t is defined as double or anything else that's not a signed integer.

@cpython-cla-bot
Copy link

@cpython-cla-bot cpython-cla-bot bot commented May 17, 2022

All commit authors signed the Contributor License Agreement.
CLA signed

@thp thp force-pushed the ctypes_c_time_t branch 2 times, most recently from 9d077ff to f8a8dd3 Compare May 17, 2022
@thp
Copy link
Contributor Author

@thp thp commented Jun 10, 2022

Bump after 24 days of no activity. Any takers for reviewing this PR?

@m-tmatma
Copy link

@m-tmatma m-tmatma commented Jun 10, 2022

@thp
It seems azure pipeline test was failed.
You should re-trigger it.

c_time_t = c_int64
elif SIZEOF_TIME_T == 4:
c_time_t = c_int32

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thp
Is it ok not to define else case?

Copy link
Contributor Author

@thp thp Jun 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If time_t is not 32-bit or 64-bit, ctypes.c_time_t will not be defined. I haven't seen a system where it's not 32-bit or 64-bit, but if we encounter such a system, the right type mapping can be added then.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thp
I think you should add to raise an exception on else case to make sure.
It may not happen, but it is a good practice to consider such exceptional case.

Copy link
Contributor Author

@thp thp Jun 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR updated, now raises an exception.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems I had approved this PR yesterday before the PR was updated,
But it was a mistake. I made it on a smart phone.

It seem I can't dismiss the approval for this repository.

@thp
Copy link
Contributor Author

@thp thp commented Jun 10, 2022

@thp
It seems azure pipeline test was failed.
You should re-trigger it.

Is there a way to manually re-trigger it? I don't seem to have permissions. I can of course amend the commits and force-push to indirectly re-trigger a build?

@arhadthedev
Copy link
Contributor

@arhadthedev arhadthedev commented Jun 10, 2022

Is there a way to manually re-trigger it

You can close and reopen the PR.

@thp thp closed this Jun 10, 2022
@thp thp reopened this Jun 10, 2022
@m-tmatma
Copy link

@m-tmatma m-tmatma commented Jun 10, 2022

@thp

Is there a way to manually re-trigger it? I don't seem to have permissions. I can of course amend the commits and force-push to indirectly re-trigger a build?

There is another way to re-trigger.

You can comment /AzurePipelines run or /azp run to a PR.
https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#comment-triggers

Copy link
Member

@AA-Turner AA-Turner left a comment

Seems reasonable, please add tests though.

A

Doc/library/ctypes.rst Outdated Show resolved Hide resolved
Lib/ctypes/__init__.py Outdated Show resolved Hide resolved
@AA-Turner AA-Turner requested review from abalkin, amauryfa and meadori Jun 11, 2022
@AA-Turner
Copy link
Member

@AA-Turner AA-Turner commented Jun 11, 2022

Pinging listed names from the experts index for review.

A

@AA-Turner AA-Turner added the type-feature label Jun 11, 2022
thp and others added 3 commits Jun 11, 2022
…oBkw.rst

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
@@ -28,6 +28,9 @@ def test_size_t(self):
def test_ssize_t(self):
self.assertEqual(sizeof(c_void_p), sizeof(c_ssize_t))

def test_time_t(self):
self.assertIn(sizeof(c_time_t), (4, 8))
Copy link
Contributor Author

@thp thp Jun 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simple test case added.

As the reason for c_time_t is mostly to get the size of the object out of it, test_sizes.py is probably the best place to test for this. This test is mostly about checking for the existence of the field, and that it's 4 or 8. If/when platforms are found that have a differently-sized c_time_t, this test can be updated.

In the future, if we find a platform where c_time_t is of a different type (different size or even non-integer type), some other tests could be added.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you compare sizeof(c_time_t) with SIZEOF_TIME_T?

Copy link
Member

@AA-Turner AA-Turner Jun 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like you should be able to use an independent version from _testcapi.

A

@thp
Copy link
Contributor Author

@thp thp commented Jun 11, 2022

Found that the ctypes documentation's "Calling functions" documentation does this (without setting restype):

>>> print(libc.time(None))  
1150640792

This uses the default return type of int, which is wrong on systems that use 64-bit time_t (and just a happy coincidence on systems that use 32-bit time_t and happen to have 32-bit int):

>>> from ctypes import *
>>> libc = CDLL("libc.so.6")
>>> libc.time
<_FuncPtr object at 0x...>
>>> libc.time.restype
<class 'ctypes.c_int'>

Updated the documentation accordingly with setting libc.time.restype to the newly-added c_time_t, even though this introduces the concept of restype and argtypes quite early, but it's probably for the best, as not doing it can result in wrong return types as seen here. Alternatively, another libc function could be used for the "Calling functions" section, and libc.time used as an example for the "Return types" section.

The libc.time.restype == c_int error will be noticeable from 2038 onwards due to 32-bit overflow, at least on systems that have 64-bit time_t and 32-bit int (all modern systems?).

@AA-Turner
Copy link
Member

@AA-Turner AA-Turner commented Jun 11, 2022

Alternatively, another libc function could be used for the "Calling functions" section, and libc.time used as an example for the "Return types" section.

I think this is a better approach. (Thanks for noticing!)

A

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

Successfully merging this pull request may close these issues.

None yet

6 participants