The buffer is initialized from right-to-left in initialize(), and unused
bytes are left alone. Previously, the whole result wasn't preinitialized
with T.init, so the unused buffer bytes weren't well-defined. Initialize
it now (with zeros), as the whole buffer is still used for equality/
identity comparisons etc.
There are multiple issues with that commit, incl. out-of-bounds read
on x86 systems and a significant performance decrease for qualified
floating-point types; see #8124 for a full list of flaws.
I'm questioning the tackled goal in the first place, because I expect
users to use that `pow` mainly with small integral exponents, *not*
expecting underflows to 0 or overflows to ±infinity, so optimizing
for these cases and sacrificing performance for the regular case doesn't
make a lot of sense to me.
When checking whether `T.toString` for some class `T` is inherited from
base class `Object`.
The runtime check fails when using a druntime DLL on Windows, where
`Object.toString` in other DLLs/executables is a trampoline (in the
druntime import library) to the dllimported function, with its own
identity.
First of all, the DDoc currently says that:
"Leading zero is allowed, but not required."
The current implementation doesn't respect that.
D lexer allows leading zero(s) also.
And when considering octal from string, there is no possibility
of confusion, as the comments in the code claim. Disallowing
leading zeros for octal conversion from string, does not help
with anything actually.
So lets allow leading zeros.
Allowing leading zeros, does help when implementing various
APIs (i.e. glibc, Linux kernel), where a lot of octal constant,
are defined with multiple leading zeros, for readability and
alignment, in C headers. Having to manually or automatically
special case these when porting such API definitions, is
counter-productive.
Example from a Linux kernel (`include/uapi/linux/stat.h`):
```c
#define S_IFMT 00170000
#define S_IFSOCK 0140000
#define S_IFLNK 0120000
#define S_IFREG 0100000
#define S_IFBLK 0060000
#define S_IFDIR 0040000
#define S_IFCHR 0020000
#define S_IFIFO 0010000
#define S_ISUID 0004000
#define S_ISGID 0002000
#define S_ISVTX 0001000
```
With this patch, now it is trivial and easier to convert these to D:
```d
...
enum S_ISVTX = octal!"0001000";
```
while being close to original. That helps with readability,
and long term maintenance.
In fact the run-time version provided by `parse!(int)(string, 8)`
also supports leading zeros already. So this makes `octal`
more consistent `parse`.
