add _l versions of strtod family functions, purely as aliases this is a cheat since the _l versions take an extra argument, but since these functions are only here for ABI purposes, it doesn't really matter as long as the ABI matches. if the non-__-prefixed versions are eventually made public, they should proabably be real functions rather than hacks like this.
support STB_GNU_UNIQUE symbol bindings in dynamic linker these are needed for some C++ library binaries including most builds of libstdc++. I'm not entirely clear on the rationale. this patch does not implement any special semantics for them, but as far as I can tell, no special treatment is needed in correctly-linked programs; this binding seems to exist only for catching incorrectly-linked programs.
change jmp_buf to share an underlying type and struct tag with sigjmp_buf this is necessary to meet the C++ ABI target. alternatives were considered to avoid the size increase for non-sig jmp_buf objects, but they seemed to have worse properties. moreover, the relative size increase is only extreme on x86[_64]; one way of interpreting this is that, if the size increase from this patch makes jmp_buf use too much memory, then the program was already using too much memory when built for non-x86 archs.
fix heap corruption bug in memalign this bug was caught by the new footer-corruption check in realloc and free. if the block returned by malloc was already aligned to the desired alignment, memalign's logic to split off the misaligned head was incorrect; rather than writing to a point inside the allocated block, it was overwriting the footer of the previous block on the heap with the value 1 (length 0 plus an in-use flag). fortunately, the impact of this bug was fairly low. (this is probably why it was not caught sooner.) due to the way the heap works, malloc will never return a block whose previous block is free. (doing so would be harmful because it would increase fragmentation with no benefit.) the footer is actually not needed for in-use blocks, except that its in-use bit needs to remain set so that it does not get merged with free blocks, so there was no harm in it being set to 1 instead of the correct value. however, there is one case where this bug could have had an impact: in multi-threaded programs, if another thread freed the previous block after memalign's call to malloc returned, but before memalign overwrote the previous block's footer, the resulting block in the free list could be left in a corrupt state. I have not analyzed the impact of this bad state and whether it could lead to more serious malfunction.
enhance build process to allow selective -O3 optimization the motivation for this patch is that the vast majority of libc is code that does not benefit at all from optimizations, but that certain components like string/memory operations can be major performance bottlenecks. at the same time, the old -falign-*=1 options are removed, since they were only beneficial for avoiding bloat when global -O3 was used, and in that case, they may have prevented some of the performance gains. to be the most useful, this patch will need further tuning. in particular, research is needed to determine which components should be built with -O3 by default, and it may be desirable to remove the hard-coded -O3 and instead allow more customization of the optimization level used for selected modules.
undefine internal-use type macros at the end of alltypes.h this patch is something of a compromise for a compatibility regression discovered after the header refactoring: libtiff uses _Int64 for its own use. this is absolutely wrong, invalid C, and should not be supported, but it's also frustrating for users when code that used to work suddenly breaks. rather than leave the breakage in place or change musl internals to accommodate broken software, I've found a change that makes the problem go away and improves musl. by undefining these macros at the end of alltypes.h, the temptation to use them in other headers is removed. (for example, I almost used _Int64 in sys/types.h to define u_int64_t rather than adding it back to alltypes.h.) by confining use of these macros to alltypes.h, we keep it easy to go back and change the implementation of alltypes later, if needed.