[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: llvm / clang / scan-build of the Hurd
From: |
Thomas Schwinge |
Subject: |
Re: llvm / clang / scan-build of the Hurd |
Date: |
Fri, 25 Oct 2013 15:48:06 +0200 |
User-agent: |
Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu) |
Hi!
On Tue, 22 Oct 2013 22:42:18 +0200, Samuel Thibault <samuel.thibault@gnu.org>
wrote:
> Justus Winter, le Tue 22 Oct 2013 17:12:54 +0200, a écrit :
> > Note the "", on my linux box that reads "/usr/bin/clang"
> > instead. Thoughts?
>
> I've noticed that in the llvm toolchain things are
> missing/missconfigured indeed. That's probably related.
Remember that I still have pending patches for LLVM/clang upstream to
properly support GNU Hurd.
<http://www.gnu.org/software/hurd/open_issues/llvm.html>. I shall resume
working on that "later"...
> > The static analyzer is good at spotting errors, see [0] for a partial
> > build of the Hurd using scan-build.
>
> They seem worth having a look at indeed.
Absolutely! As well as... obviously... dare I say it: GCC compiler
warnings. (I'm aware you fixed several of these already/recently.)
<http://www.gnu.org/software/hurd/open_issues/code_analysis.html>.
When I recently read about it somewhere, I've also had the idea about
feeding the Hurd code into the Coverity scanner, which I think offers
such a service for Free Software projects. I also thought about dping
the same for GNU Mach and glibc, and for each of these, including the
stub files generated by MIG, for "self-containedness".
> > Clang does not support nested functions [1],
> > iiuc [...] the semantic is not too well defined.
There are some notes about this on
<http://www.gnu.org/software/hurd/open_issues/multithreading.html>, IRC,
freenode, #hurd, 2012-07-16. I have however not reviewed this.
> > I propose to deprecate their use for the Hurd and to gradually rewrite
> > the code that uses them, starting with the core libraries, to make it
> > possible to analyze them using the static analyzer.
>
> If it's not too hard, it can be useful to get better exposure to
> static analysis indeed. Nested functions are however sometimes really
> convenient, that may not be always easy to replace.
I'm not opposed to reducing/abandon their usage, but as you say, we
should probably do this case by case.
Grüße,
Thomas
pgpjDRNgtNLpO.pgp
Description: PGP signature