Skip to content

Conversation

@olegrok
Copy link
Contributor

@olegrok olegrok commented Jul 27, 2020

Since 23be848 (Validate/long: final rewrite) "long" type
validation started to handle string representation of numbers.
This happens because "tonumber" function implicitly casts some
strings to numbers. That allows to pass strings (e.g. "123") instead
of "long".

This patch fixes such behaviour and introduces corresponding
test. Currently we will try to cast to number only fields that
have "number" or "cdata" type.

Closes #133

@olegrok olegrok requested a review from Totktonada July 27, 2020 15:33
…type

Since 23be848 (Validate/long: final rewrite) "long" type
validation started to handle string representation of numbers.
This happens because "tonumber" function implicitly casts some
strings to numbers. That allows to pass strings (e.g. "123") instead
of "long".

This patch fixes such behaviour and introduces corresponding
test. Currently we will try to cast to number only fields that
have "number" or "cdata" type.

Closes #133
@olegrok olegrok force-pushed the olegrok/133-string-as-long-validation branch from 03960bb to be54c65 Compare August 7, 2020 15:21
Comment on lines +772 to +775
local n
if type(data) == 'number' or type(data) == 'cdata' then
n = tonumber(data)
end
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Alternative way that also could be used.
Do something like

local _
_ = data > 0 -- it throws for non-numeric types (e.g. for strings)

@Totktonada
Copy link
Contributor

23be848 is weird: it does not explain why to use such hacky way to validate a value. Better for JIT? Observed better performance?

The code version before 23be848 is easier to understand and now we anyway check the type explicitly. Maybe it would be logical to just revert the commit. However I don't mind your minimal change.

@Totktonada
Copy link
Contributor

At least is solved the observed problem and does not lead to any visible functional degradation.

Copy link
Contributor

@Totktonada Totktonada left a comment

Choose a reason for hiding this comment

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

LGTM.

@Totktonada Totktonada merged commit 31c9fdd into master Sep 9, 2021
@Totktonada Totktonada deleted the olegrok/133-string-as-long-validation branch September 9, 2021 21:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

validation for "long" allows "string"

3 participants