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

Overflow prepare stdlib #7256

Merged

Conversation

bcardiff
Copy link
Member

@bcardiff bcardiff commented Jan 3, 2019

The PR updates the stdlib to use unchecked operations & conversions where needed.

The changes should be read as: keep the current semantic once the operations will default to overflowing.

Some changes direct make sense because they manipulate data as bits mainly (eg: hasher).
Some might look a bit odd (eg: dwarf, floatprinter). The changes were required to make specs pass once the overflow is turned on.
Other changes can be revised in future version (eg: time) since there is manual detection of overflow that could be simpler in the future.

src/number.cr Show resolved Hide resolved
@bcardiff bcardiff merged commit 78c6a59 into crystal-lang:master Jan 3, 2019
@@ -45,7 +45,7 @@ module Debug
code = DWARF.read_unsigned_leb128(@io)
attributes.clear

if abbrev = abbreviations[code - 1]? # abbreviations.find { |a| a.code == abbrev }
if abbrev = abbreviations[code &- 1]? # abbreviations.find { |a| a.code == abbrev }
Copy link
Contributor

Choose a reason for hiding this comment

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

There should be heavily TODO'd, or compiled into an issue. If we just do a blanket "everything which fails due to overflow gets the old semantics" we miss a fantastic opportunity to get rid of bugs!

src/json/from_json.cr Show resolved Hide resolved
@@ -95,7 +95,7 @@ struct Pointer(T)
# TODO: If throwing on overflow for integer conversion is implemented,
# then (here and in `Pointer#-`) for a `UInt64` argument the call to
# `to_i64` should become `as_unsafe`.
Copy link
Contributor

Choose a reason for hiding this comment

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

This comment should have been replaced with an explanation.

@RX14
Copy link
Contributor

RX14 commented Jan 3, 2019

This is a huge missed opportunity. The non-obvious cases where unchecked arithmetic is used must be accompanied by a comment, and all the uses must be audited.

I have no confidence that if we say we'll do those bugfixes and refactors "after we've implemented overflow", that they'll ever get done. There at the very least needs to be a high-priority issue enumerating these cases, and actively working on fixing them. And this issue needs to be completed before 0.27.1. Silently copying the existing behaviour is very dangerous.

@bcardiff
Copy link
Member Author

bcardiff commented Jan 4, 2019

I do want to refactor but we can't for example refactor Time to use overflow until overflow is the default behavior (or we need to have a huge macro if to use overflow if enabled). I think that is better to than after.

Other cases like dwarf requires some more digging and I wasn't able to dig deeper without further time. At worst, we are emitting the same code as before. Not worse.

I expect that there are some more missing parts of the std lib that will need s/+/&+/ but were not detected with the current spec coverage.

This PR is a whole TODO after overflow is turned on IMO. But doing it before will requiere code duplication or efforts that can happen later and improve stdlib once we have more a solid ground.

@RX14
Copy link
Contributor

RX14 commented Jan 5, 2019

@bcardiff I'm fine with leaving time, since it has a comment. I'm fine with leaving DWARF too, but it needs a comment or an issue or something to track this technical debt which has just been created.

JSON and YAML should be refactored before 0.27.1. Number.slice should be raise-on-overflow for 0.28.0. There are also some comments that need to be updated, but thats less of an issue.

@RX14
Copy link
Contributor

RX14 commented Mar 22, 2020

Have we done any of these refactors?

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

Successfully merging this pull request may close these issues.

3 participants