Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

gh-141370: Fix undefined behavior when using Py_ABS()#141548

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
serhiy-storchaka merged 6 commits intopython:mainfromserhiy-storchaka:Py_ABC-UB
Dec 5, 2025

Conversation

@serhiy-storchaka
Copy link
Member

@serhiy-storchakaserhiy-storchaka commentedNov 14, 2025
edited by bedevere-appbot
Loading

Comment on lines 313 to 315
uint64_t abs_value = long_export.value < -INT64_MAX
? (uint64_t)INT64_MAX + (uint64_t)-(long_export.value + INT64_MAX)
: (uint64_t)Py_ABS(long_export.value);
Copy link
Member

Choose a reason for hiding this comment

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

Can't we assume two's complement representation of integers and use simpler workaround? As this fix span several places, I would prefer if it could be refactored to a separate macro.

I.e. something like:

#defineMy_ABS(x,MAX) \    ((x) < 0 ? ((x) >= -MAX ? -(x) : (U##MAX >> 1) + 1) : (x))

Nowadays two's complement is only case permitted by the C23 and is a de-facto standard. Do you have some system in mind on which we should care? I'm pretty sure all Tier 1-3 platforms fit to this picture.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

All Tier 1-3 platforms perhaps fine with the current code. We change the code because we cannot be sure that it work on all exotic platforms and that future versions of the C compiler will not interpret an undefined behavior in interesting way.

The current gcc does not generate additions and substractions for this PR. It generates something more smart, although not so smart as forPy_ABS(). Although for your proposition it generates more complex code.

Details

#include<limits.h>#definePy_ABS(x) ((x) < 0 ? -(x) : (x))#defineMy_ABS(x,MAX) \    ((x) < 0 ? ((x) >= -MAX ? -(x) : (U##MAX >> 1) + 1) : (x))unsignedintintabs0(intx) {return (unsignedint)Py_ABS(x);}unsignedintintabs(intx) {returnx<-INT_MAX        ? (unsignedint)INT_MAX+ (unsignedint)-(x+INT_MAX)        : (unsignedint)Py_ABS(x);}unsignedintintabs2(intx) {returnMy_ABS(x,INT_MAX);}unsigned longlongabs0(longx) {return (unsigned long)Py_ABS(x);}unsigned longlongabs(longx) {returnx<-LONG_MAX        ? (unsigned long)LONG_MAX+ (unsigned long)-(x+LONG_MAX)        : (unsigned long)Py_ABS(x);}unsigned longlongabs2(longx) {returnMy_ABS(x,LONG_MAX);}

Anyway, the performance of this code is not critical (if there is any difference).

Copy link
Member

Choose a reason for hiding this comment

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

All Tier 1-3 platforms perhaps fine with the current code.

(Yes, and I suspect tests might be redundant in fact.)

Although for your proposition it generates more complex code.

A different version:

#define__GMP_CAST(type,expr) ((type) (expr))#defineNEG_CAST(T,x) (- (__GMP_CAST (T, (x) + 1) - 1))#defineABS_CAST(T,x) ((x) >= 0 ? __GMP_CAST (T, x) : NEG_CAST (T, x))

I found same approach in the GNU GMP, so just copied NIH code here.

Anyway, the performance of this code is not critical (if there is any difference).

Your solution looks ok for me. But in any case we should factor it to some macro.

serhiy-storchaka reacted with thumbs up emoji
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

For this version gcc generates exactly the same code as for the current code. But it is now free from undefined behavior.

@skirpichevskirpichev self-requested a reviewNovember 15, 2025 02:00
Copy link
Member

@skirpichevskirpichev left a comment

Choose a reason for hiding this comment

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

LGTM

This version triggers a warning on M$ compiler, but this is probably ok.

#define Py_MAX(x, y) (((x) > (y)) ? (x) : (y))

/* Absolute value of the number x */
#define _Py_ABS_CAST(T,x) ((x) >= 0 ? ((T) (x)) : (- (((T) ((x) + 1)) - 1)))
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
#define_Py_ABS_CAST(T,x) ((x) >= 0 ? ((T) (x)) : (- (((T) ((x) + 1)) - 1)))
#define_Py_ABS_CAST(T,x) ((x) >= 0 ? ((T) (x)) : (- (((T) ((x) + 1)) - 1)))

Copy link
Member

@picnixzpicnixzNov 18, 2025
edited
Loading

Choose a reason for hiding this comment

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

For posterity:

_Py_ABS_CAST(uint8_t, (int8_t)-128)==128

The(T)((x) + 1) - 1 is:

( (   (uint8_t) (     (-128)+1// -127 (still int8_t)   )// 129 (2's complement on 8 bits) )-1// 128 (as an uint8_t))

Since$-128\bmod{256} = 128$, we are good. For another number say-5 we have:

( (   (uint8_t) (     (-5)+1// -4 (still int8_t)   )// 252 (2's complement on 8 bits) )-1// 251 (as an uint8_t))

And now$-251 \bmod{256} = 5$ and we're good.

@serhiy-storchakaserhiy-storchaka merged commit706fdda intopython:mainDec 5, 2025
44 checks passed
@miss-islington-app
Copy link

Thanks@serhiy-storchaka for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

@serhiy-storchakaserhiy-storchaka deleted the Py_ABC-UB branchDecember 5, 2025 14:24
miss-islington pushed a commit to miss-islington/cpython that referenced this pull requestDec 5, 2025
…-141548)(cherry picked from commit706fdda)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
@miss-islington-app
Copy link

Sorry,@serhiy-storchaka, I could not cleanly backport this to3.13 due to a conflict.
Please backport usingcherry_picker on command line.

cherry_picker 706fdda8b360120a25b272898df40c8913381723 3.13

@bedevere-app
Copy link

GH-142301 is a backport of this pull request to the3.14 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.14bugs and security fixes labelDec 5, 2025
serhiy-storchaka added a commit to serhiy-storchaka/cpython that referenced this pull requestDec 5, 2025
…ythonGH-141548)(cherry picked from commit706fdda)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
@bedevere-app
Copy link

GH-142304 is a backport of this pull request to the3.13 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.13bugs and security fixes labelDec 5, 2025
Yhg1s pushed a commit that referenced this pull requestDec 5, 2025
…) (#142304)(cherry picked from commit706fdda)Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
StanFromIreland pushed a commit to StanFromIreland/cpython that referenced this pull requestDec 6, 2025
…-141548)Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
serhiy-storchaka added a commit that referenced this pull requestDec 12, 2025
…) (GH-142301)(cherry picked from commit706fdda)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@skirpichevskirpichevskirpichev approved these changes

@picnixzpicnixzpicnixz approved these changes

Labels

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@serhiy-storchaka@skirpichev@picnixz

[8]ページ先頭

©2009-2026 Movatter.jp