If there was even an easy way to get involved in OpenSource development in general - this is it. It's pretty much a list of trivial 1-line bugs to fix!
Rebuild of the Debian archive with clang
21–30 of 55 posts
Re: Rebuild of the Debian archive with clang
#22Earlier quoted context omitted.
It can be proven, see CompCert C compiler: http://compcert.inria.fr/compcert-C.html .
That only proves that a compiler behaves according to a language definition. That does not prove the executables will behave as you expect the executables to behave, and thus there is no way knowing the executables will be error free.
Frownie said error-free compilation, not error-free in all possible aspects.
Re: Rebuild of the Debian archive with clang
#23Earlier quoted context omitted.
Doesn't Apple use clang for OS X? If it does, that's as good a validation as any for me.
Isn't most of their code in Objective C? Does that use clang too?
clang does support Objective C (as does gcc).
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.
Re: Rebuild of the Debian archive with clang
#24Amazing list. 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?
The build logs are all together: http://clang.debian.net/logs/2012-01-12/ (I guess the ones with a 'b' appended are for clang)
Fantastic, just what I was after. Thanks a lot!
And phew, my package was not listed. :)
Re: Rebuild of the Debian archive with clang
#25Why is everyone itching to get off of GCC? Or is it all just posturing, to get GCC to work harder now that it has competition?
Re: Rebuild of the Debian archive with clang
#26Why is everyone itching to get off of GCC? Or is it all just posturing, to get GCC to work harder now that it has competition?
GCC is becoming larger and more unmaintainable with each release. Competition in this space has been pretty sorely lacking for quite some time. The OpenBSD folks are also pushing PCC as a GCC alternative.
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.
Re: Rebuild of the Debian archive with clang
#27Why is everyone itching to get off of GCC? Or is it all just posturing, to get GCC to work harder now that it has competition?
sane error messages are worth the switch alone.
Re: Rebuild of the Debian archive with clang
#28Looks like the most comprehensive list of differences between clang and gcc. I'm amazed. 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.
If you put basic standard compliance aside, it also strips down the errors from arguable code to horrifying coding practice. http://clang.debian.net/status.php?version=3.0&key=VARIA... http://clang.debian.net/status.php?version=3.0&key=NON-P...
Really I never got the argument for disallowing variable-length arrays at the end of a C structure. I completely agree with disallowing non-PoD variable-length arrays as well as variable-length arrays in the middle of a structure though.
Re: Rebuild of the Debian archive with clang
#29Earlier quoted context omitted.
No one can ever prove such a thing. Neither can it be proven that gcc or any compiler for that matter produces error-free executables. What this does, however, is providing information and analysis about the quality of the clang compilation process as compared to gcc.
No can prove it, but at least the GCC version are actually run by people - these version and created, but never actually used. 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.
As an example, gcc generates nearly unusable code for a Via Isaiah in amd64 mode if you compile with -O1, and this has apparently been a known issue for at least 2 years.
Re: Rebuild of the Debian archive with clang
#30Earlier quoted context omitted.
If you put basic standard compliance aside, it also strips down the errors from arguable code to horrifying coding practice. http://clang.debian.net/status.php?version=3.0&key=VARIA... http://clang.debian.net/status.php?version=3.0&key=NON-P...
Really I never got the argument for disallowing variable-length arrays at the end of a C structure. I completely agree with disallowing non-PoD variable-length arrays as well as variable-length arrays in the middle of a structure though.
The entire concept of variable-length C arrays is at best iffy, but including them in structs is pretty crazy.
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?