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.

Sign up for GitHub

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

Jump to bottom

remove support for platforms without "long long" #72148

Closed
benjaminp opened this issue Sep 5, 2016 · 18 comments
Closed

remove support for platforms without "long long" #72148

benjaminp opened this issue Sep 5, 2016 · 18 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@benjaminp
Copy link
Contributor

BPO 27961
Nosy @scoder, @vstinner, @benjaminp, @encukou, @vadmium, @serhiy-storchaka, @pablogsal, @miss-islington
PRs
  • bpo-27961: Replace PY_LLONG_MAX, PY_LLONG_MIN and PY_ULLONG_MAX with standard macros #15385
  • bpo-27961: Replace PY_LONG_LONG with long long #15386
  • bpo-27961: Remove leftovers from the times when long long wasn't required #15388
  • [3.8] bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388) #15392
  • [3.7] bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388) #15393
  • bpo-27961: Replace PY_ULLONG_MAX with ULLONG_MAX #17539
    		•
    Files
  • longlong.patch
    		•

    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:

    assignee = None
closed_at = <Date 2016-09-06.00:45:27.037>
created_at = <Date 2016-09-05.23:50:29.594>
labels = ['interpreter-core', 'type-feature']
title = 'remove support for platforms without "long long"'
updated_at = <Date 2019-12-09.20:22:24.133>
user = 'https://github.com/benjaminp'

    bugs.python.org fields:

    activity = <Date 2019-12-09.20:22:24.133>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2016-09-06.00:45:27.037>
closer = 'python-dev'
components = ['Interpreter Core']
creation = <Date 2016-09-05.23:50:29.594>
creator = 'benjamin.peterson'
dependencies = []
files = ['44384']
hgrepos = []
issue_num = 27961
keywords = ['patch']
message_count = 18.0
messages = ['274473', '274483', '274484', '274485', '274486', '276881', '276910', '276929', '284593', '284772', '284773', '350197', '350206', '350207', '350602', '355026', '357853', '358138']
nosy_count = 9.0
nosy_names = ['scoder', 'vstinner', 'benjamin.peterson', 'petr.viktorin', 'python-dev', 'martin.panter', 'serhiy.storchaka', 'pablogsal', 'miss-islington']
pr_nums = ['15385', '15386', '15388', '15392', '15393', '17539']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue27961'
versions = ['Python 3.6']
    @benjaminp
    Copy link
    Contributor Author

    Neither Python 2.7 nor 3.3+ compile without HAVE_LONG_LONG, so effectively this is already completely unsupported. Let's completely dump it in 3.6.

    @benjaminp benjaminp added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels Sep 5, 2016
    @vadmium
    Copy link
    Member

    vadmium commented Sep 6, 2016

    Makes sense if it already doesn’t work without HAVE_LONG_LONG. This also came up in discussion of adding a BLAKE2 hash algorithm: <https://www.mail-archive.com/search?l=mid&q=CAMpsgwZJ47osOt597YedkAqXisu3b_4giTBXSMq6GH%2B_yLf2aw@mail.gmail.com\>.

    FWIW the normal Windows compiler may not actually have “long long”; we use __int64 instead:

    https://hg.python.org/cpython/annotate/default/PC/pyconfig.h#l267

    so maybe in some places (such as this bug title) you should refer to PY_LONG_LONG rathe than “long long” to avoid confusion :)

    @vstinner
    Copy link
    Member

    vstinner commented Sep 6, 2016

    Python/pytime.c of Python 3.5 requires a 64-bit integer type and Py_LONG_LONG. Nobody complains, so I'm in favor of dropping all these annoying HAVE_LONG_LONG and just use directly Py_LONG_LONG. It should simplify the code at lot!

    By the way, it would be cool to get intmax_t and uintmax_t types in Python (C code). These types are more convenient than having to play with #ifdef or if (value < ..._MAX).

    @benjaminp
    Copy link
    Contributor Author

    MSVC 2008 (at least) is documented to have "long long", too. https://msdn.microsoft.com/en-us/library/s3f49ktz(v=vs.90).aspx

    In fact, after this patch, I'm probably going to go s/PY_LONG_LONG/long long/.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Sep 6, 2016

    New changeset 9206a86f7321 by Benjamin Peterson in branch 'default':
    require a long long data type (closes bpo-27961)
    https://hg.python.org/cpython/rev/9206a86f7321

    @python-dev python-dev mannequin closed this as completed Sep 6, 2016
    @scoder
    Copy link
    Contributor

    scoder commented Sep 18, 2016

    Removing HAVE_LONG_LONG entirely causes breakage of third party code that uses this macro to enable PY_LONG_LONG support. Could you please always define it instead of removing it?

    @vstinner
    Copy link
    Member

    It seems fair to keep the define for backwrad compatibility.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Sep 19, 2016

    New changeset cf6e9968ebb7 by Benjamin Peterson in branch '3.6':
    always define HAVE_LONG_LONG (bpo-27961)
    https://hg.python.org/cpython/rev/cf6e9968ebb7

    @encukou
    Copy link
    Member

    encukou commented Jan 3, 2017

    The backwards compatibility is not as strong as it could be: previously, HAVE_LONG_LONG was defined to 1; now it's defined but empty.

    At least that's the case on Fedora.
    Found in the Python plugin for GCC: https://bugzilla.redhat.com/show_bug.cgi?id=1409009

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jan 5, 2017

    New changeset fad67c66885f by Victor Stinner in branch '3.6':
    Issue bpo-27961: Define HAVE_LONG_LONG as 1.
    https://hg.python.org/cpython/rev/fad67c66885f

    @vstinner
    Copy link
    Member

    vstinner commented Jan 5, 2017

    The backwards compatibility is not as strong as it could be: previously, HAVE_LONG_LONG was defined to 1; now it's defined but empty.

    Oh, right. This issue should now be fixed as well.

    @pablogsal
    Copy link
    Member

    New changeset a38e9d1 by Pablo Galindo (Sergey Fedoseev) in branch 'master':
    bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388)
    a38e9d1

    @miss-islington
    Copy link
    Contributor

    New changeset 2878f37 by Miss Islington (bot) in branch '3.8':
    bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388)
    2878f37

    @miss-islington
    Copy link
    Contributor

    New changeset d0da97d by Miss Islington (bot) in branch '3.7':
    bpo-27961: Remove leftovers from the times when long long wasn't required (GH-15388)
    d0da97d

    @serhiy-storchaka
    Copy link
    Member

    This issue was closed 2.5 years ago. Would not be better to open a new issue for new commits?

    @serhiy-storchaka
    Copy link
    Member

    New changeset a9ed91e by Serhiy Storchaka (Sergey Fedoseev) in branch 'master':
    bpo-27961: Replace PY_LONG_LONG with long long. (GH-15386)
    a9ed91e

    @vstinner
    Copy link
    Member

    vstinner commented Dec 5, 2019

    New changeset 1f9f69d by Victor Stinner (Sergey Fedoseev) in branch 'master':
    bpo-27961: Replace PY_LLONG_MAX, PY_LLONG_MIN and PY_ULLONG_MAX with standard macros (GH-15385)
    1f9f69d

    @vstinner
    Copy link
    Member

    vstinner commented Dec 9, 2019

    New changeset a2ff283 by Victor Stinner (Sergey Fedoseev) in branch 'master':
    bpo-27961: Replace PY_ULLONG_MAX with ULLONG_MAX (GH-17539)
    a2ff283

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    8 participants
    @vstinner @benjaminp @encukou @scoder @vadmium @serhiy-storchaka @pablogsal @miss-islington