История изменений
Исправление
ckotinko,
(текущая версия)
:
http://jibbering.com/faq/notes/type-conversion/
ToInt32 is an internal function only available to the Javascript implementation and cannot be called directly from scripts in the way that parseInt can. It is a bit unusual to mention it in connection with converting Javascript values to numbers but it can be used in a limited set of circumstances. The bitwise operators such as bitwise OR (|) and bitwise AND (&) operate on numbers so they type-convert their operands to numbers. However, they also only operate on 32 bit signed integers so given the (possibly type-converted) numeric value they call the internal ToInt32 function with that number as its argument and use the returned value as their operand. That returned value is always a 32 bit signed integer.
NaN -> 0
Лол, теперь понятно что произошло. у оптимизатора V8 вычисление констант походу имеет два бага. Первый: оно видимо пугается NaNов и недовычисляет до конца. Иначе бы проблемы не было
((1-ff(NaN) >>> 0) % 0xdc4e153) =
((1-NaN >>> 0) % 0xdc4e153) =
(ToInt32(NaN) >>> 0) % 0xdc4e153) = а вот теперь расхождение
в JS:(0 >>> 0) % 0xdc4e153) = 0 % 0xdc4e153 = 0,
0 & v = 0, и если бы оптимизатор честно досчитал до сюда, он бы просто уничтожил все матоперации и оставил бы m[0]=0x12345678;
но он где-то напугался(думаю что на NaN->int) и оставил вычисления как есть, при этом считая их результат константой. константа убила проверку лимита(т.е. её результат стал константой = false). а сам код NaN->int другой багокод превратил в fistp или cvtsd2si.
итог (0xfbebebeb >>> 0) & 0xdc4e153) это короче совсем не 0.
Если моя догадка верна, то там ШЕРЕТО в выломаным дном. и да, возможно это ШЕРЕТО было встроено намерено.
причем шерето сознательно кем-то спроектированное, что должно быть видно в структурах и коде оптимизатора. т.к. constant subexpression elimination дошло до проверки лимита, но при этом не обрубило дерево до этой проверки. врода как там константа, но её не свели к константе а оставили вычисляться
Исправление
ckotinko,
:
http://jibbering.com/faq/notes/type-conversion/
ToInt32 is an internal function only available to the Javascript implementation and cannot be called directly from scripts in the way that parseInt can. It is a bit unusual to mention it in connection with converting Javascript values to numbers but it can be used in a limited set of circumstances. The bitwise operators such as bitwise OR (|) and bitwise AND (&) operate on numbers so they type-convert their operands to numbers. However, they also only operate on 32 bit signed integers so given the (possibly type-converted) numeric value they call the internal ToInt32 function with that number as its argument and use the returned value as their operand. That returned value is always a 32 bit signed integer.
NaN -> 0
Лол, теперь понятно что произошло. у оптимизатора V8 вычисление констант походу имеет два бага. Первый: оно видимо пугается NaNов и недовычисляет до конца. Иначе бы проблемы не было
((1-ff(NaN) >>> 0) % 0xdc4e153) =
((1-NaN >>> 0) % 0xdc4e153) =
(ToInt32(NaN) >>> 0) % 0xdc4e153) = а вот теперь расхождение
в JS:(0 >>> 0) % 0xdc4e153) = 0 % 0xdc4e153 = 0,
0 & v = 0, и если бы оптимизатор честно досчитал до сюда, он бы просто уничтожил все матоперации и оставил бы m[0]=0x12345678;
но он где-то напугался(думаю что на NaN->int) и оставил вычисления как есть, при этом считая их результат константой. константа убила проверку лимита(т.е. её результат стал константой = false). а сам код NaN->int другой багокод превратил в fistp или cvtsd2si.
итог (0xfbebebeb >>> 0) & 0xdc4e153) это короче совсем не 0.
Если моя догадка верна, то там ШЕРЕТО в выломаным дном. и да, возможно это ШЕРЕТО было встроено намерено.
Исходная версия
ckotinko,
:
Ыыыыыы
http://jibbering.com/faq/notes/type-conversion/
ToInt32 is an internal function only available to the Javascript implementation and cannot be called directly from scripts in the way that parseInt can. It is a bit unusual to mention it in connection with converting Javascript values to numbers but it can be used in a limited set of circumstances. The bitwise operators such as bitwise OR (|) and bitwise AND (&) operate on numbers so they type-convert their operands to numbers. However, they also only operate on 32 bit signed integers so given the (possibly type-converted) numeric value they call the internal ToInt32 function with that number as its argument and use the returned value as their operand. That returned value is always a 32 bit signed integer.
NaN -> 0
Лол, теперь понятно что произошло. у оптимизатора V8 вычисление констант походу имеет два бага. Первый: оно видимо пугается NaNов и недовычисляет до конца. Иначе бы проблемы не было
((1-ff(NaN) >>> 0) % 0xdc4e153) =
((1-NaN >>> 0) % 0xdc4e153) =
(ToInt32(NaN) >>> 0) % 0xdc4e153) = а вот теперь расхождение
в JS:(0 >>> 0) % 0xdc4e153) = 0 % 0xdc4e153 = 0,
0 & v = 0, и если бы оптимизатор честно досчитал до сюда, он бы просто уничтожил все матоперации и оставил бы m[0]=0x12345678;
но он где-то напугался(думаю что на NaN->int) и оставил вычисления как есть, при этом считая их результат константой. константа убила проверку лимита(т.е. её результат стал константой = false). а сам код NaN->int другой багокод превратил в fistp или cvtsd2si.
Если моя догадка верна, то там ШЕРЕТО в выломаным дном. и да, возможно это ШЕРЕТО было встроено намерено.