Issue 7792031: Fixing issue 1645, removing detection of octal numbers through 0-prefix.

Keyboard Shortcuts

	File
u :	up to issue
j / k :	jump to file after / before current file
J / K :	jump to next file with a comment after / before current file
	Side-by-side diff
i :	toggle intra-line diffs
e :	expand all comments
c :	collapse all comments
s :	toggle showing all comments
n / p :	next / previous diff chunk or comment
N / P :	next / previous comment
<Up> / <Down> :	next / previous line

	Issue
u :	up to list of issues
j / k :	jump to patch after / before current patch
o / <Enter> :	open current patch in side-by-side view
i :	open current patch in unified diff view

	Issue List
j / k :	jump to issue after / before current issue
o / <Enter> :	open current issue

Issue 7792031: Fixing issue 1645, removing detection of octal numbers through 0-prefix. (Closed)

Created:
9 years, 3 months ago by Yang

Modified:
9 years, 3 months ago

Reviewers:
Lasse Reichstein, Sven Panne, Jakob Kummerow

CC:
v8-dev

Base URL:
https://v8.googlecode.com/svn/branches/bleeding_edge

Visibility:
Public.

Description

Fixing issue 1645, removing detection of octal numbers through 0-prefix. BUG=v8:1645

Patch Set 1 #

Created: 9 years, 3 months ago

Download [raw] [tar.bz2]

		Unified diffs	Side-by-side diffs	Delta from patch set	Stats (+5 lines, -5 lines)			Patch
	M	src/conversions-inl.h	View		1 chunk	+1 line, -1 line	0 comments	Download
	M	test/mjsunit/parse-int-float.js	View		1 chunk	+4 lines, -4 lines	0 comments	Download

Messages

Total messages: 3 (0 generated)

Expand Messages | Collapse Messages

Yang

Fixing a valid issue. Though I have concerns that this patch might "break the Internet", ...

9 years, 3 months ago (2011-08-30 07:49:40 UTC) #1

Jakob Kummerow

The patch itself LGTM. I don't have any data or experience regarding whether this would ...

9 years, 3 months ago (2011-08-30 08:01:24 UTC) #2

Sven Panne

9 years, 3 months ago (2011-08-30 08:13:44 UTC) #3

On 2011/08/30 08:01:24, Jakob wrote:
> The patch itself LGTM.
> 
> I don't have any data or experience regarding whether this would "break the
web"
> or not. Generally I think we should try to follow the latest ES spec.
> 
> How about putting this change into a custom Chromium build and running it
> through layout tests and some manual browsing?

The current Firefox 6 has still the old behavior, so I would be very careful
about such a change. Perhaps we should enable the new behavior only when a
related flag has been set and/or in strict mode. I am not really sure how we
handle such backwards compatibility breaking changes normally...

Expand Messages | Collapse Messages