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

[Richard Braun]

On Fri, Oct 25, 2013 at 02:32:08PM -0700, Roland McGrath wrote:
> > Clang does not support nested functions [1], and there is no plan to
> > support them upstream. As such, any file that uses nested functions
> > (or any gcc extension not supported by clang) is excluded from the
> > analysis (see e.g. [2]). Richard has no special love for them, iiuc
> > b/c the semantic is not too well defined. I propose to deprecate their
> > use for the Hurd and to gradually rewrite the code that uses them,
> 
> That's a non-starter.  They are an excellent extension and their semantics
> are thoroughly well-defined.
> 

Unless I'm mistaken, their semantics imply executable stacks, which is
great for security, and they don't bring anything we couldn't do with
regular callbacks, except adding indentation levels, which is also great
for code clarity, in addition to being the most painful GNU extension to
implement in other code-related tools like static analyzers.

In other words, we don't really need them, they increase security risks,
and they prevent us from using nice tools.

The real problem with deprecating them is that some function pointers
used by glibc code, such as demuxers used by mach_msg_server_timeout,
can't easily be modified to take a generic void * pointer without
breaking the ABI. Those function pointers were intended to be nested
functions from the start.

-- 
Richard Braun