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

41–50 of 55 posts

Re: Rebuild of the Debian archive with clang

#41

Post by ori_b »

nknight wrote: post #40
ori_b wrote: post #36

Earlier quoted context omitted.

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.

Well, in the normal case, you wouldn't do it. These variable length structures need to be created on the heap to be able to be used in a variable length way, for the most part, so you'd just put a pointer to them into an array.

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]
To get to the i'th element of a, accesses would go through idx like so: a[idx[i]]. In general, of course, there's no way to allow O(1) access and updates without occasional repacking.

Re: Rebuild of the Debian archive with clang

#43

Post by udp »

viraptor wrote: post #21

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!

And patches to generate, mailing lists to find and emails to write. If only every open source project were on GitHub.

Re: Rebuild of the Debian archive with clang

#44

Post by nknight »

ori_b wrote: post #41
nknight wrote: post #40

Earlier quoted context omitted.

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

Well, in the normal case, you wouldn't do it. These variable length structures need to be created on the heap to be able to be used in a variable length way, for the most part, so you'd just put a pointer to them into an array. 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] To get to the i'th element of a, a…

This is exactly the problem I'm getting at, you're not actually working within the confines of C here, you're creating funny workarounds for the fact that certain C features don't work how you want them to, and you're violating the type system in the process.

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.

Re: Rebuild of the Debian archive with clang

#45

Post by malkia »

gregheo wrote: post #23
smackfu wrote: post #18

Earlier quoted context omitted.

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.

If I'm not mistaken, the drivers are also written in C++ (They used to be in Objective-C).

Re: Rebuild of the Debian archive with clang

#46

Post by emaste »

gtufano wrote: post #10
abc_lisper wrote: post #8

Earlier quoted context omitted.

Doesn't Apple use clang for OS X? If it does, that's as good a validation as any for me.

Another (IMHO better) validation is that FreeBSD compiles the kernel with clang: http://wiki.freebsd.org/BuildingFreeBSDWithClang

FreeBSD has made a lot of progress with clang in the base system (which consists of both the kernel and standard userland); I run a clang-compiled FreeBSD on my laptop.

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

Re: Rebuild of the Debian archive with clang

#47

Post by lambda »

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?

This kind of work is valuable even without getting rid of GCC. Each compiler has a slightly different implementation of warnings; getting the code to compile under two compilers can find issues that you wouldn't find under just one compiler.

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.

Re: Rebuild of the Debian archive with clang

#48

Post by adbge »

cliffbean wrote: post #38
nknight wrote: post #35

Earlier quoted context omitted.

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.

    $ gcc -v
    ...
    gcc version 4.6.2 20120120 (prerelease) (GCC)
When it comes to diagnostics, GCC isn't even competitive.

Re: Rebuild of the Debian archive with clang

#49

Post by viraptor »

udp wrote: post #43
viraptor wrote: post #21

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!

And patches to generate, mailing lists to find and emails to write. If only every open source project were on GitHub.

That's also something I meant by getting involved in open source. I'm sure for some projects you'll have to figure out its local rules, sometimes maybe even explain to the developers what's clang, why the change is required to support it and why they should care. It's the whole experience, not only code change ;)

Re: Rebuild of the Debian archive with clang

#50

Post by gillianseed »

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…

Well Clang/LLVM is also becoming larger with each release. As for GCC becoming more 'unmaintainable', can you point me to anything supporting that notion? It's certainly not unmaintainable now as proven by them regularly releasing new improved versions which serve as the de facto compiler toolchain for open source systems.

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.

Post reply on HN