A special treat to go with the release, that's not linked on the website yet: in-browser demo setup using jslinux: http://www.musl-libc.org/jslinux/
162 karma · joined June 2, 2012
- Symbol versioning: If you have a newer glibc installed when you build your packages, they'll refuse to run on older glibc, even if they don't need any of the new version's features. This makes it hard to make packages that support multiple versions of a distribution (e.g. a stable release with an older glibc and an unstable release with a newer one).
- Awkwardness of upgrading: For example Debian usually wants you to restart X and any daemons that use nss when glibc is updated. There are also atomicity issues during upgrade where there's a race window during which execing programs can fail.
On the other hand, distros are invested in a huge set of packages as well as support for third-party (often non-free) software, all of which are presently linked with glibc. I think musl is a lot more interesting right now to new and upcoming distros that are looking for a fresh start with less baggage than as a migration path for the big distros with major user/customer bases, at least in the short term. In the long term, who knows what will happen... :-)
CHAR_BIT==8 was not mandated by POSIX until 2001 when it was aligned with C99, and seems to have been mandated as a consequence of C99's requirement that [u]intXX_t types not have any padding bits, and the requirement (in POSIX) that network-related interfaces use uint8_t, uint16_t, and uint32_t (which, per C99, cannot all exist unless CHAR_BIT==8).
With that said, musl's current default is way too low. It's caused problems with several major applications such as git. We're in the process of trying to establish a good value for the default, which will likely end up being somewhere between 32k and 256k. I'm thinking 80k right now (96k including guard page and POSIX thread-local storage) but I would welcome evidence/data that helps make a good choice.
1 & 2. I don't see any reason to believe there will ever be a new machine with non-power-of-two word size, and I'm doubtful that there are even any historical post-standardization C implementations like that. Certainly Linux, which makes much bigger assumptions about word size and the relationship of types, will never support such hypothetical systems. Generality is good if it buys you anything practical, but my approach has been to avoid excess generality unless it has a practical benefit. This approach has been very beneficial in the dynamic linker, wherein assuming that things that are the same on real-world archs actually are the same, the amount of per-arch code to maintain is only some 30 lines (which might grow to 60-100 once TLS is supported), as opposed to many hundreds or even thousands in other implementations.
At this point, musl does not have official documentation/manual. When it does, these sorts of requirements as well as all the implementation documentation required by ISO C and POSIX will be documented.
3. The casts are all necessary (C does not define implicit conversions between pointer types) and correct. Casting to (void *) rather than an explicit type is my preference because it reduces duplication of the type in multiple places, but in any case this is purely a stylistic matter and has nothing to do with the generated code or correctness.
4. The ONES macro was leftover from other files on which this code was based (strchr and strcpy). Obviously it's not needed in memcpy which copies a fixed number of bytes without searching for any terminator character, so it could/should be removed. Thanks for catching this.