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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
