Strange Behaviour with Numbers That Have a Leading Zero

Strange behaviour with numbers that have a leading zero

If you simply write 08 and 09 (without quotes) or any other numeric with a leading 0, PHP believes you're writing an octal value, and 08 and 09 are invalid octal numbers.

http://www.php.net/manual/en/language.types.integer.php

Syntax

Integers can be specified in decimal (base 10), hexadecimal (base 16),
octal (base 8) or binary (base 2) notation, optionally preceded by a
sign (- or +).

Binary integer literals are available since PHP 5.4.0.

To use octal notation, precede the number with a 0 (zero). To use
hexadecimal notation precede the number with 0x. To use binary
notation precede the number with 0b.

[...]

Warning:
Prior to PHP 7, if an invalid digit was given in an octal integer (i.e. 8 or 9), the rest of the number was ignored. Since PHP 7, a parse error is emitted.

Dividend result with leading zero is 2.5 instead of 3. Why?

Your variable is being interpreted as an octal. Per the docs:

To use octal notation, precede the number with a 0 (zero). To use
hexadecimal notation precede the number with 0x. To use binary
notation precede the number with 0b.

Read more: http://php.net/manual/en/language.types.integer.php

Why are integer literals with leading zeroes interpreted strangely?

A leading zero denotes that the literal is expressed using octal (a base-8 number).

0123 can be converted by doing (1 * 8 * 8) + (2 * 8) + (3), which equals 83 in decimal.
For some reason, octal floats are not available.

Just don't use the leading zero if you don't intend the literal to be expressed in octal.

There is also a 0x prefix which denotes that the literal is expressed in hexadecimal (base 16).

Strange behavior with PHP's str_pad() and numbers

You don't need to compute the difference you just put the total characters you want it to be.

str_pad(strval($caseid), 6, '0', STR_PAD_LEFT);

php array behaving strangely with key value 07 & 08

Prepending 0 before a number means PHP parses it as an octal value in the same way that prepending 0x causes it to be parsed as a hexadecimal value. Remove the zero, and it will work fine.

echo 07; // prints 7
echo 010; // prints 8

This is mostly used when specifying unix permissions:

chmod("myfile", 0660);

Except for that it's rarely something that you'd want to do.

This is described in the PHP Manual.

weird behavior when writing numbers in the console

This has nothing to do with jQuery; it's just a feature / quirk of ECMAScript (and therefore JavaScript). Numeric literals beginning with 0 are interpreted in octal, rather than decimal (except in strict mode, in which case it produces a syntax error).

You can verify this by observing 012 === 10 and 0123 === 83.

Strange behaviour when finding largest number in Array

Your loop is executing one time too many. The loop termination condition i <= SIZE will result in the loop body accessing arr[SIZE], which is outside of the arr array -- remember that C array indices start at 0.

Since the array is stored in the stack frame, your code will be fetching some garbage value from the stack located at the first address beyond the array. This garbage value could be anything, and so could be a large positive value, resulting in what you are seeing.

Javascript strict equal strange behaviour

Because 01000, 512, 0o535, and 349 are all numbers. 01000 and 512 are the same value written different ways (a "legacy" octal literal and a decimal literal); so are 0o535 and 349 (a new-style octal literal and a decimal literal). The form of literal you use makes no difference to the value or type of what it creates. Similarly, 'foo' === "foo" is true, even though I use the single-quoted string literal in one and the double-quoted string literal in the other.

About the two kinds of octal literals:

01000 is a "legacy" octal literal, indicated by just the leading zero. JavaScript engines in web browsers are required (as of ES2015) to support them in loose mode, and to not support them in strict mode (e.g., "use strict"). (Note that loose mode and strict mode have nothing to do with loose equality and strict equality, which is a separate concept.) So in a compliant, browser-based JavaScript engine, 01000 === 512 is true in loose mode, but an error in strict mode, because legacy octal literals are not allowed in strict mode. (Prior to ES2015, supporting legacy octal literals in loose mode was not required.)

0o535 is the newer octal notation added in ES2015, indicated with the leading 0o. It's supported in both loose and strict modes by compliant JavaScript engines. But again, it's new, so older browsers won't be compliant.

---

Related Topics