LINUX.ORG.RU

История изменений

Исправление 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.

Если моя догадка верна, то там ШЕРЕТО в выломаным дном. и да, возможно это ШЕРЕТО было встроено намерено.