I disagree. There is a big difference between invalid input to a function (eg trying to convert "abc" to an integer) and a memory corruption bug. In the former case, you can return an error to the caller, and if they were written with enough attention to detail, they can fix the problem and move on, or ask the user for actually valid input, or whatever followup action may be appropriate.

In the case of a memory corruption bug, there is no way to correct the problem and move on. By the time you detect the problem, you're already hosed. You can't even rely on the fact that the program accurately knows what it was in the middle of trying to do. I think crashing is absolutely appropriate here. And if you want to debug it, then attach a debugging to the program or the resulting core dump -- all the same information you would have gotten from printed diagnostics can be found (albeit with more effort). But trying to diagnose a memory corruption bug after the fact like this is the hard way to do it anyway. You really want to catch the corruption as it happens, and the are much better tools for this (valgrind, etc).

This list is probably not absolutely 100% complete, but it should be pretty close:

• A number of header files defining system call numbers, and structures for interfacing with the kernel. Musl does not require or use the linux kernel headers, so these definitions must be provided by the port itself.
• Assembly code for making system calls. There's an inline function version, an implementation of the variadic syscall(2) function, and a version for system calls that made as part of functions defined to be cancellation points
• The main _start entry point, which just needs to align the stack as appropriate for the target ABI and call __libc_start_main
• A few atomic primitives, probably written in assembly, but some architectures require calling into a kernel helper to implement these
• Assembly implementations of setjmp/longjmp
• Assembly to query/poke at the floating point state, for fenv support
• Assembly for returning from a signal
• Assembly for a couple threading things (getting/setting the thread pointer, terminating the calling thread)
• A couple specific system calls. Clone requires an assembly version. A couple architectures return the result of the pipe syscall via registers, which also requires an assembly implementation on those architectures.
• A little code to handle the few dynamic relocation types particular to the architecture (which are likely to be identical to those used by other architectures, just with different numbers)
• Optionally, optimized assembly versions for some math functions, memcpy, and such

You can find links to more information on the musl wiki.

putw is a non-standard function that musl's headers only expose to programs when they define _GNU_SOURCE.or _BSD_SOURCE. The file that actually implements it, therefore, needs to define one of these in order for the header to expose the declaration, which allows the compiler to verify that the type signatures of the declaration and the definition match.

Where does it say you have to link the whole thing into your application? Musl supports dynamic linking just fine. The musl developers do have a preference for static linking, so they have better support for it than glibc (see their size comparisons of static linked programs on musl and glibc, for instance). But that doesn't mean you have to use it.

The bit about aiming for correctness is correctness of musl itself. Of course they can't, in general, guarantee that you will write your own code correctly. In theory, they could split the math library out and force you to link against it correctly. But what would be the point? To arbitrarily break broken programs, while having no impact on correct programs? It would also have several downsides.

Musl is the only C library I'm aware of which allows the entire C library ecosystem (C library, math library, threading library, dynamic linker, and some others probably) to be upgraded atomically, which eliminates a small window during upgrade where you might start a new program and have it break because it gets conflicting versions of these components.

There is also code within the main C library (for example, the code to format floating point numbers in printf) which benefits from being able to call functions that are part of the math library.

You're right that musl doesn't support the same breadth of architectures that glibc does. They currently support x86, amd64, ARM, MIPS, PPC, microblaze, and they have experimental support for superh and x32.

One big advantage they do have is that it's much simpler to add support for a new architecture to musl than it is to add it to glibc. They are interested in supporting more architectures, so I'd expect their list of supported architectures to grow fairly quickly if there are people interested in that support.

The first priority on musl is correctness, and they will take a hit to size and speed if that's what's necessary to achieve it. But thus far, they've been doing a good job of achieving correctness without introducing too much bloat.

Take a look at their page on bugs found while developing musl, and you'll find that they've found and reported quite a few bugs in glibc where glibc had been "cutting corners".

You do realize that CMS only published the final rule for stage 2 on August 23, right?

How have they taken the phone manufacturer out of the equation? They _are_ the phone manufacturer.

You should have written "should've written."

ARM can be configured to run as either little or big endian. Instructions are always stored in memory in little endian, but not necessarily so for data. Little endian is more common, but the ARM processor in the Wii, for example, is big endian.

Look at the post he was replying to:

Sentex wasn't explicit about it, but in context it's obvious that he was talking about constitutionally-protected free speech.

Javascript, maybe. I don't have much experience with it, so I can't comment.

But I have to disagree with HTML. HTML is not programming. Seriously, making a simple webpage in HTML is like typing a document in Word, except typing <b>text</b> instead of hitting the bold button on the toolbar. If that's programming, then typing up a paper for high school English class is too.

HTML _can_ lead into Javascript, PHP, and other facets of web programming. But it's not programming in itself, and if the goal is to introduce him to programming, making him learn HTML before he can start learning programming seems like the wrong way to go about it.

> But video games just let the market decide what will happen if it is too expensive

Part of the way the market decides on the price is that people complain when it is too expensive.

I haven't looked at the official changelog or the code yet, but I'm just as confused as you about that item. Moreso perhaps, as I have used IPv4 over firewire with two linux machines before. That was probably 5 years ago or so.

It's still missing an infrared port for transmitting phone numbers and such too, isn't it?