fix posixmodule for 64-bit systems (mainly Win64)

[bdaf8532-ded6-4d4c-9bb3-51fd76040dc1]

BPO	400513
Nosy	@tim-one, @freddrake
Files	None: None

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = 'https://github.com/freddrake' closed_at = created_at = labels = [] title = 'fix posixmodule for 64-bit systems (mainly Win64)' updated_at = user = 'https://bugs.python.org/tmick' ``` bugs.python.org fields: ```python activity = actor = 'fdrake' assignee = 'fdrake' closed = True closed_date = None closer = None components = ['None'] creation = creator = 'tmick' dependencies = [] files = ['2444'] hgrepos = [] issue_num = 400513 keywords = ['patch'] message_count = 7.0 messages = ['32730', '32731', '32732', '32733', '32734', '32735', '32736'] nosy_count = 3.0 nosy_names = ['tim.peters', 'fdrake', 'tmick'] pr_nums = [] priority = 'normal' resolution = None stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue400513' versions = [] ```

[bdaf8532-ded6-4d4c-9bb3-51fd76040dc1]

[freddrake]

Committed verbatim.

[tim-one]

Accepted and assigned back to Trent.

I hate parts of this patch but can't think of anything substantially better without massive changes everywhere. For example, testing whether SIZEOF_TIME_T > SIZEOF_LONG and then *assuming* LONG_LONG is long enough is the same kind of dubious assumption that broke on Win64. The new dubious assumptions are likely to hold true for years to come, but it's still unprincipled. Still, all in all, fixes a real problem now and a principled alternative is A Project.

[tim-one]

Hmm. Assigning back to Trent. Could have sworn I did that the first time!

[bdaf8532-ded6-4d4c-9bb3-51fd76040dc1]

I confirm that, to the best of my knowledge and belief, this contribution is free of any claims of third parties under copyright, patent or other rights or interests ("claims"). To the extent that I have any such claims, I hereby grant to CNRI a nonexclusive, irrevocable, royalty-free, worldwide license to reproduce, distribute, perform and/or display publicly, prepare derivative versions, and otherwise use this contribution as part of the Python software and its related documentation, or any derivative versions thereof, at no cost to CNRI or its licensed users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide whether or not to incorporate this contribution in the Python software and its related documentation. I further grant CNRI permission to use my name and other identifying information provided to CNRI by me for use in connection with the Python software and its related documentation.

[bdaf8532-ded6-4d4c-9bb3-51fd76040dc1]

This patch fixes the posix module for large file support mainly on Win64, although some general cleanup is done as well.

The changes are:

• abstract stat->STAT, fstat->FSTAT, and struct stat->STRUCT_STAT This is because stat() etc. are not the correct functions to use on Win64 (nor maybe on other platforms?, if not then it is now trivial to select the appropriate one). On Win64 the appropriate system functions are _stati64(), etc.
• add _pystat_fromstructstat(), it builds the return tuple for the fstat system call. This functionality was being duplicated. As well the construction of the tuple was modified to ensure no overflow of the time_t elements (sizeof(time_t) > sizeof(long) on Win64).
• add overflow protection for the return values of posix_spawnv and posix_spawnve
• use the proper 64-bit capable lseek() on Win64
• use intptr_t instead of long where appropriate from Win32/64 blocks (sizeof(void*) > sizeof(long) on Win64)

[bdaf8532-ded6-4d4c-9bb3-51fd76040dc1]

test comment to see if 'tim_one', the current patch owner, will get a notification message for this comment