Skip to content

Fix parseInt when passing empty string #430

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

Closed
wants to merge 1 commit into from

Conversation

galpeter
Copy link
Contributor

Corrected the base buffer size for the string.

JerryScript-DCO-1.0-Signed-off-by: Peter Gal pgal.u-szeged@partner.samsung.com

@galpeter galpeter added bug Undesired behaviour ecma builtins Related to ECMA built-in routines labels Jul 17, 2015
@galpeter galpeter added this to the ECMA builtins milestone Jul 17, 2015
@galpeter
Copy link
Contributor Author

Related issue: #428

@@ -112,7 +112,7 @@ ecma_builtin_global_object_parse_int (ecma_value_t this_arg __attr_unused___, /*
ecma_string_t *number_str_p = ecma_get_string_from_value (string_var);
lit_utf8_size_t str_size = ecma_string_get_size (number_str_p);

MEM_DEFINE_LOCAL_ARRAY (utf8_string_buff, str_size, lit_utf8_byte_t);
MEM_DEFINE_LOCAL_ARRAY (utf8_string_buff, str_size + 1, lit_utf8_byte_t);
Copy link
Contributor

Choose a reason for hiding this comment

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

@galpeter, as string is empty in the test case from #428, maybe we don't need to process it. So, instead of +1 we could put the code into if block with fastpath for empty string.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ruben-ayrapetyan, yeah that's why I was thinking initially, thus I have this: galpeter@f3081a0 would that be ok?

Copy link
Contributor

Choose a reason for hiding this comment

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

@galpeter, yes, I think this would be ok.

@galpeter
Copy link
Contributor Author

@ruben-ayrapetyan, I've updated the PR, and now it uses if check.

@ruben-ayrapetyan
Copy link
Contributor

Looks good to me

@dbatyai
Copy link
Member

dbatyai commented Jul 20, 2015

LGTM

@galpeter galpeter force-pushed the fix_428_b branch 2 times, most recently from 0ad90c5 to 96d315a Compare July 21, 2015 14:19
{
/* Not a valid number char, set value to radix so it fails to pass as a valid character. */
utf8_string_buff[i] = (lit_utf8_byte_t) rad;
if ((utf8_string_buff[i]) >= 'a' && utf8_string_buff[i] <= 'z')
Copy link
Member

Choose a reason for hiding this comment

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

Literals has constants (defines) for these characters. Please use them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zherczeg, I don't think it is wise to replace the with the equivalent LIT_ define, as those are ecma_char_t types (unit16_t), but here we use lit_utf8_byte_t (unit_8_t). Should I really replace the constants?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zherczeg, I've got a follow up fix, which rewrites the parseInt to use the lit_iterators to support unicode characters and there the constants are fixed. So should I also include the constants in this PR?

@zherczeg
Copy link
Member

Please fix the above, and LGTM after that.

@galpeter
Copy link
Contributor Author

@zherczeg, I've replaced the character constants with the LIT_.. macros.

@galpeter galpeter removed their assignment Jul 22, 2015
Before allocating buffer for the string first
we check that the length of it is greater then 0.
If not then the result is a NaN.

JerryScript-DCO-1.0-Signed-off-by: Peter Gal pgal.u-szeged@partner.samsung.com
@galpeter
Copy link
Contributor Author

Landed: ee8d650

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Undesired behaviour ecma builtins Related to ECMA built-in routines
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants