[Top][All Lists]

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


On Tue, 22 Oct 2013 22:42:18 +0200, Samuel Thibault <samuel.thibault@gnu.org> 
> 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.)

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.


Attachment: pgpjDRNgtNLpO.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]