Rebuild of the Debian archive with clang

Consider these two questions:

1) What is the sizeof a struct containing a variable-length array?

2) How do you create an array of structs containing variable-length arrays?

However, if you read the standard, you'll realize that it would have involved specifying far more exceptional cases than the mostly equivalent solution via flexible array members (ie allowing the last member to have incomplete array type).

Another few cool things: If elements "know about themselves" (have a size element or a vtable etc etc) you can make stacks and queues without the need for a separate index.

There are also a few things you can probably only do in ASM: Say you have an "array" of objects "inheriting" from a common base (with sizes depending on their type) and all you ever want to do with them is iterate over them calling virtual functions on them. A nice way to do it would be to keep the iteration logic at the end of the virtual functions (which know about the sizes of their respective objects) and do something that smells a little like tail-call-elimination, maybe with a sentinel object on the end to wrap things up nicely. To get the best bang for your buck you'd need an architecture that isn't preachy about the stack or calling conventions, of course, but it still might be worth doing for a laugh.

Erm, I guess this wasn't too clear. In some pseudocode below:

    virtual void Factorial::process_and_print() {
        //processing logic:
        this->n *= (++this->i);
        print(this->n);
    
        //iteration logic:
        this += sizeof(Factorial);
        this->process(); //must do TCO
    }
    virtual void Message::process_and_print() {
        //processing logic:
        print(this->message);
    
        //iteration logic:
        this += sizeof(Message);//message stored by pointer
        this->process();
    }
    virtual void Sentinel::process() {
        //iteration logic:
        return;
    }
    funnyArray<Processable> fa;
    fa.add(Factorial(1));
    fa.add(Message("hello"));
    fa.add(Sentinel());
    fa.run(process); //prints something like "1hello"

Even if we started with a small test set for some projects, it would be a huge win in the long run just to have this scaffolding in place.

Any ideas on how to make a distro-agnostic testing hook?

But that said, we have a lot more clang coverage through the work done by the ports team who have been running experimental builds with clang for more than a year. That work is documented here: http://wiki.freebsd.org/PortsAndClang

Apple does look after a lot of plain old C (e.g. Core Foundation) and C++ (e.g. WebKit) too, so clang handles all three.

Saying we're comparing old versions isn't really useful unless the new versions have actually addressed the relevant issues.

Afraid? I expect that these companies have spent serious money on lawyers to figure out whether GPL 3 was acceptable for them before committing to it.

Also, Mac OS supports OpenCL (http://en.wikipedia.org/wiki/OpenCL). One could argue that that makes the compiler more a part of the OS than "just another application that runs on it". If they used GPL code there, a perceived risk could be that they could be forced to make their OS GPL.