`OneOfDescriptor_each` is registered as a Ruby method which takes zero
parameters, which means it should take one argument.
When Ruby invokes `OneOfDescriptor_each`, it calls it with one parameter
only, which is one less than what `OneOfDescriptor_each` takes before
this commit. Calling a function with the wrong number of argument is
technically undefined behavior.
See also: §6.5.2.2, N1256
When browsing around the strutil files I found a function
that was never referenced inside the code base
"void StripString(string* s, const char* remove,
- char replacewith);"
The name was kind of misleading as well and it seems like
it's a carbon copy of
"void ReplaceCharacters(string* s, const char* remove,
char replacewith);"
(even the parameter names are the same, the code is the same..)
Is it intentional? Maybe for compatibility reasons? If so,
let's make it deprecated and use the ReplaceCharacters method inside
or the other way around.
Also, noticed there were no tests for "StripString" or "Replace".
Added some for both and planning on maybe making it more C++ish (?)
in another commit.
The OSReadLittleInt64 function as defined by Apple reduces down to:
`return *(volatile uint64_t *)((uintptr_t)base + byteOffset);`
which means we are type-punning using a cast. On ARMv7 and other aligned architectures this can cause crashes.
Minimal example: https://gist.github.com/dmaclach/b10b0a71ae614d304c067cb9bd264336Fixes#6679
The code in question hasn't change in a long time so the cause of
https://github.com/firebase/firebase-ios-sdk/issues/3851 still appears to be
an Xcode 11 clang change/bug; but this does appear to be slightly better
code for the work being done.
Cleanup along the way for #6679
The OSReadLittleInt64 function as defined by Apple reduces down to:
`return *(volatile uint64_t *)((uintptr_t)base + byteOffset);`
which means we are type-punning using a cast. On ARMv7 and other aligned architectures this can cause crashes.
Minimal example: https://gist.github.com/dmaclach/b10b0a71ae614d304c067cb9bd264336Fixes#6679