Apparently, most differences are either because clang and gcc use different standards or interpret them differently.

Also, only 9% of the Debian packages have issues, meaning clang is getting more and more worth considering.

http://clang.debian.net/status.php?version=3.0&key=VARIA...

http://clang.debian.net/status.php?version=3.0&key=NON-P...

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"

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?

    /* c89 */
    struct {
        int len;
        int vla[1]; /* really len elements long */
    } MyVLAStruct;

Can you provide code demonstrating how you will "carefully" create a C array of structs with a variable-sized member? It will be very educational for me, at least, and I think others, as well.

However, I can think of a couple of methods, such as packing into an array, and using a second one to index it, like so:

    a   = [aaaa,bb,ccc,dd]
    idx = [0,4,6,9]

The concept of VLAs does not fit the language well, they're inherently something of an anomaly. Allowing them in structs would simply multiply the anomalies.

I'm frankly shocked that they were codified in C99 at all, rather than codifying something akin to alloca() with implementation-defined behavior, but I'm infinitely grateful the committee did not elect to make them anything more than they are -- which is a semi-portable mechanism for allocating arbitrary amounts of automatic memory.

Going a step further, wouldn't it be great if all packages had automated tests that could easily be run on the 91% of the packages that were successfully built?

I was frustrated that I didn't manage to figure out how to locate the results for a given package, if there were any.

Without that, how should I (as a package upstream owner) know if I need to fix my code, or at least analyze the results with respect to my particular package?

http://clang.debian.net/logs/2012-01-12/

(I guess the ones with a 'b' appended are for clang)

And phew, my package was not listed. :)

  Building libgtkada.so.2.14.2
  cd obj-shared; x86_64-linux-gnu-gcc -shared -fPIC -Wl,--as-needed \
  	  -o libgtkada.so.2.14.2 -Wl,-soname,libgtkada.so.2.14.2 glib*.o gdk*.o \
  	  gtk*.o pango*.o misc.o misc_broken.o -lgtk-x11-2.0 -lgdk-x11-2.0 \
  	  -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 \
  	  -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype \
  	  -lfontconfig -lgobject-2.0 -lgmodule-2.0 \
  	  -lgthread-2.0 -lrt -lglib-2.0   -lgnat -lX11
  Segmentation fault

The others: http://clang.debian.net/status.php?version=3.0&key=SEG_F...

He should do some fuzz testing of these programs, with the exact same fuzz sent to the GCC versions, and then report any differences. But collecting the "results" would be hard - it's not always visible in output, you'd have to track system calls and IO.

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?

Debian packages can already hook the upstream's test suite (e.g. via dh_auto_test).

From my (extremely limited and mostly dynamic language) Debian packaging experience, it seems that more often than not, packages do not use this existing hook. Not sure why that is though.

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.

It'll be nice to have a BSD-licenced GCC equivalent for distribution with FreeBSD/OpenBSD, too.

Clang also has REALLY great error messages compared to GCC. It will tell you exactly where you forgot a comma, semicolon, quote, etc. instead of randomly pointing to some line around the error in question.

Apple and various BSD's stopped updating GCC around version 4.2, the last GPLv2 version, which is approximately 4 years old now. For people who only develop on those platforms, this is what "GCC" means. So when someone from Apple or someone with an obvious BSD bias talks about how much better clang is than "GCC", they're usually talking about how much better clang is than an old unmaintained version of GCC.

clang does have strengths, but when we make comparisons, we should be clear about what it is we're comparing.

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

If you're comparing clang to just GCC 4.2, then say that. If you've compared it with recent versions of GCC too, then say that.

    $ gcc -v
    ...
    gcc version 4.6.2 20120120 (prerelease) (GCC)

Also when speaking of GCC and how old and full of cruft it is, you need to realize that it's code base is being continously improved with each new release with a strong focus on modularity. It's not the same codebase as it was back in 1987.

I'm very happy Clang/LLVM exists and progressing at a great pace as I see increased availability of open source compiler toolchains as something awesome. Also LLVM really does have some great features like the best-in-class error reporting and it also serves an undeniable purpose as a jit framework for numerous projects.

That said I don't understand those trying to push the idea of GCC being obsolete (unless they are nurturing some political/licence based crusade) as it's a very mature compiler toolchain targeting a large number of architectures and (atleast for me) quite importantly generating faster code than Clang/LLVM.

Also the notion that companies would be afraid of GCC strikes me as odd given that we have Red Hat, IBM, Google, CodeSourcery, Suse etc employing full-time GCC developers.

I hope to see these compiler toolchains continously going neck to neck in the future and thus provide the open source ecosystem with two first class options each with their respective strenghts.

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.

It also increases flexibility for developers. Perhaps I prefer to use Clang for its better error messages, or because I find it easier to target at a new platform that I'm working on. If the code already runs under Clang, then that's work I don't have to do. Clang can also be used as an independent parser more easily for GCC, so tools that use it to generate code browsing information or the like benefit from the code already being parseable with Clang.

Compiling under another compiler will also catch more of the cases in which you're depending on non-portable behavior or extensions, which increases the likelihood that you will be able to run it under static analyzers like Coverity, Clang Analyzer, Klee, Splint, or the like.

Basically, beyond wanting to move away from GCC, there is real value in putting work into making sure that everything compiles under another compiler. It's like making sure your web site works on multiple browsers; it can help you catch errors earlier, allow people to use better debugging tools, widen your audience, and help future-proof you.

Now, there are some people who are itching to get away from GCC. For one thing, it is a bigger, older, wartier project, that is harder to work with. People find Clang and LLVM more modular and extensible. For another, there are some companies that are deathly afraid of the GPLv3, and won't touch anything to do with it (Apple in particular, as well as some other embedded device manufacturers I believe). But there are many reasons for wanting to make sure that your software compiles under Clang, and not all of them mean that you want to ditch GCC, just that Clang provides additional value as well.