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

[SR-11942] There is no recoverable overflow policy for FixedWidthInteger.dividingFullWidth #54362

Open
swift-ci opened this issue Dec 11, 2019 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-11942
Radar rdar://problem/57888486
Original Reporter CTMacUser (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee None
Priority Medium

md5: fecad648170634d3696a4854ab14273b

Issue Description:

The addition and subtraction operators are supplemented by methods that report a single bit of overflow. The multiplication operator has a similar one-bit of overflow method, and has a full-width method that returns the product in two words. That second variant can supplant uses of the first variant. There are one-bit of overflow methods for division and remainder, to supplement the corresponding operators. There is also a full-width version of division, that takes a two-word divisor returns single words quotient and remainder.

The problem is when there is an overflow in the division. This can be caused by using a zero divisor or if the divisor is (absolutely) so small the quotient needs two words instead of one. The documentation says this causes a runtime error. The problem is that there is no alternative. There either needs to be a `dividingFullWidthWithOverflow` method, a variant of that method that returns a double-word quotient, or a documentation note in the current method on how to test for overflow conditions (testing for a zero divisor or a divisor that would need a double-word quotient). A respondent on the initial thread expressed a desire for the third option instead of adding yet another method.

@beccadax
Copy link
Contributor

@swift-ci create

@stephentyrone
Copy link
Member

CC @natecook1000, @airspeedswift

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@wadetregaskis
Copy link

Perhaps tangential, but there's also a performance angle on this: because it assumes there can be overflow, it does extra work to check for it. Whereas if overflow is preconditionally impossible, the whole function could be inlined as a single instruction (e.g. divq on x86-64).

Perhaps there's a way to convince the compiler that overflow is impossible (without doing work at runtime, such as with precondition), such that it might be able to (with inlining) optimise the overflow checking away, but I haven't been able to find one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

4 participants