Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rebuild of the Debian archive with clang

clang.debian.net

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Rebuild of the Debian archive with clang

#31

Post by cliffbean »

getsat wrote: post #26
lhnn wrote: post #25

Why 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, semicolo…

It is useful to keep in mind a common confusion.

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.

Re: Rebuild of the Debian archive with clang

#32

Post by nas »

lhnn wrote: post #25

Why 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?

Even if everyone doesn't switch, having more than one widely used open-source C compiler would be healthy. If anything, it allows some non-portable code to be found and fixed. Also, competition is healthy. The different compiler developers can choose to focus on specific areas of improvement (e.g. compile speed vs executable speed) rather than a one-size-fits-all approach.

Re: Rebuild of the Debian archive with clang

#33

Post by johnpaulett »

rbanffy wrote: post #20
ars wrote: post #7

Earlier quoted context omitted.

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.

The ideal scenario would be if upstream projects provided embedded test code with standardized hooks so that tests could be built, executed and results collected in an automated way. 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?

It does not necessarily have to be distro-agnostic.

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.

Re: Rebuild of the Debian archive with clang

#34

Post by cygx »

aidenn0 wrote: post #28
valisystem wrote: post #11

Earlier 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.

VLAs at the end of C structures could have been allowed.

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).

Re: Rebuild of the Debian archive with clang

#35

Post by nknight »

cliffbean wrote: post #31
getsat wrote: post #26

Earlier quoted context omitted.

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, semicolo…

It is useful to keep in mind a common confusion. 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 t…

Unless there's been a concerted effort in the last ~year or so to improve GCC's error messages and compilation speed, clang's primary technical strengths remain unchanged relative to GCC.

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

Re: Rebuild of the Debian archive with clang

#36

Post by ori_b »

nknight wrote: post #30
aidenn0 wrote: post #28

Earlier quoted context omitted.

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?

1) The sum of sizes of the padding and fixed-size members of the struct. In the context of C, this is expected and fairly sane. It also matches the C89 idiom of ending a struct intended with a single element array when you want a variable length array. If C allowed zero-element arrays, then they would be used.

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

Re: Rebuild of the Debian archive with clang

#37

Post by InclinedPlane »

frownie wrote: post #3

However this doesn't proove that clang produce error-free (was afar the compiklation goes) executables.

And? Nobody expects that gcc, or intel's reference compilers, or Microsoft's compilers produce provably correct output.

How could they? The C standard contains ambiguity in several areas.

Re: Rebuild of the Debian archive with clang

#38

Post by cliffbean »

nknight wrote: post #35
cliffbean wrote: post #31

Earlier quoted context omitted.

It is useful to keep in mind a common confusion. 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 t…

Unless there's been a concerted effort in the last ~year or so to improve GCC's error messages and compilation speed, clang's primary technical strengths remain unchanged relative to GCC. Saying we're comparing old versions isn't really useful unless the new versions have actually addressed the relevant issues.

Recent versions of GCC do, in fact, have improved error messages. For example, GCC 4.6 fixed a problem that the post I was replying to mentioned, where a missing semicolon after a struct definition would cause GCC to elicit an error message pointing to some other nearby line.

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.

Re: Rebuild of the Debian archive with clang

#39

Post by sylvestre »

rbanffy wrote: post #9

This is seriously amazing and will, certainly, improve all the codebases involved. Sylvestre and the others involved deserve a lot of good karma for this. 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?

Thanks. I appreciate ! :)

Re: Rebuild of the Debian archive with clang

#40

Post by nknight »

ori_b wrote: post #36
nknight wrote: post #30

Earlier quoted context omitted.

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?

1) The sum of sizes of the padding and fixed-size members of the struct. In the context of C, this is expected and fairly sane. It also matches the C89 idiom of ending a struct intended with a single element array when you want a variable length array. If C allowed zero-element arrays, then they would be used. /* c89 */ struct { int len; int vla[1]; /* really len elements long */ } MyVLAStruct; 2) Carefully.

> 2) Carefully.

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.

Post reply on HN