jamessu

While in this case I can't think of any specific reasons beyond performance to need to implement objc_msgSend in assembly, there are absolutely instances where assembly is the only option.

Example: when performing a context switch in a kernel, assembly is required since C abstracts away architecture-specific details necessary to swap out the register set, swap the page directory pointer, etc.

I've been using arch for about 3 years and I think that things break just as often (actually, probably more often) and you're generally not left with a better sense of what the root cause is. Sure, you have less software installed, but you're also usually running bleeding-edge versions of everything and things are noticeably less stable.

I do think that from an educational standpoint, arch linux is a good OS to use, as you will probably get a lot more comfortable with the linux environment. This is largely out of necessity as you will spend a great deal of time setting up and fixing your system.

If you have the time to debug the various components of your system, it can be quite fun and educational to use, but if you're interested in getting work done I cannot recommend arch linux at all.

Very cool. I think that this is reflected in a lot of physical activities. From my personal experience with martial arts, I've definitely seen some (anecdotal) evidence to support the notion that you move more efficiently and correctly when you aren't thinking your way through it. It's cool to see some experimental support for this.

Every single program that your computer runs is nothing but a 'pile of bytes' that is carefully set up by your compiler. There is no technical reason that you cannot manually set up said byte piles and execute them, and it is actually not hard at all. (The only 'gotcha' is that some parts of memory are not marked as executable, but this can be changed at runtime or compile-time).

execve does nothing more than swap out which bytes are loaded into the address space of a program (okay, it does some other book-keeping too, but from 100 feet...). It is not necessary for continuing execution outside of what the program has set up at compile-time. In fact, you can dynamically generate code on the fly, as JIT compilers do.

Yes you can. An executable (using ELFs as an example, most formats are similar) is nothing more than some headers and bytes. The executable code can be modified in any way you please, as long as you're writing valid opcodes (the program will crash if it hits a bad opcode).

That said, it's usually much more complicated to change the size of the executable section (this requires modifying the headers and this tends to be a rather involved process), so usually if people are doing binary patches they are only modifying bytes, not adding or removing them.

I agree that we disagree. Your comment elsewhere:

> It's all about the underhanded trick(s) with the pointers, yours will never compile. I'm forcing clang to do horrible things.

Indicates, to me, that you see this as a strange behaviour that you're forcing the compiler into when in fact this is exactly the intended (and expected) semantics of const.

His point was that you aren't interpreting the `const' the same way the compiler does.

To the compiler, this:

    const int *a;
    a = NULL; // perfectly OK
    *a = 0;   // does not compile

Is a pointer to a constant int, not a constant pointer to an int.

You're probably confusing it with this:

    int *const a;
    a = NULL; // does not compile
    *a = 0;   // perfectly OK

Which is a constant pointer to a regular int.

Of course you can combine both as follows:

    const int *const a;
    a = NULL; // does not compile
    *a = 0;   // does not compile

Which is a constant pointer to a constant int (which, of course, makes no sense at all in this case since 'a' is uninitialized and cannot be initialized without an unsafe cast, but it's a perfectly valid statement in C).

I was going to remark on this. I've personally run into this writing some C that was built on multiple platforms, one of which had c99 and one of which did not (c89 instead).

I think the real issue here is the inconsistency between C standards on details like this. If you can always assume that your code is built with c99 or later, then use all of its features, but in many cases that's not a realistic assumption.

If a scheduler change breaks userland apps, that sounds like a scheduler bug to me... Any word on whether there is going to be a rollback/further scheduler changes to make spinlocks useful again?

DYLD_INSERT_LIBRARIES is more or less the OS X equivalent of LD_PRELOAD.