[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: llvm / clang / scan-build of the Hurd



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

Attachment: pgpf0IkBkD7HB.pgp
Description: PGP signature


Reply to: