[asterisk-dev] [Code Review] 4370: RAII_VAR: nested functions aren't portable. Adapting RAII_VAR to use clang/llvm blocks to get the same/similar functionality. TAKE 2

[Corey Farrell]

> On Feb. 21, 2015, 1:24 p.m., Corey Farrell wrote:
> > /branches/11/configure.ac, line 1065
> > <https://reviewboard.asterisk.org/r/4370/diff/3/?file=71557#file71557line1065>
> >
> >     I missed this before / thought Josh pointed it out.  This one should be AC_MSG_ERROR as well.
> 
> Matt Jordan wrote:
>     Replacing this with:
>      			AC_MSG_ERROR("nested-functions is required for gcc")
>     
>     Caused configure to fail:
>     
>     checking for -Wshadow... yes
>     checking for -march=native support... yes
>     checking for gcc -fnested-functions... configure: error: "nested-functions is required for gcc"
>     
>     Even though I did have nested functions....
>     
>     
>     So that's weird.
>
> 
> Matt Jordan wrote:
>     I'm actually not sure what -fnested-functions would even do. My google-foo is failing me on its use with GCC (which appears to not understand it), and since we only set that on the "false" path (that is, we failed to compile a program with a nested function), I'm not sure how it would help.
>     
>     As it is, I think I will put an AC_MSG_ERROR in the 'false' path of the compilation.

So this finding can be dropped, I was wrong.  This line (and the next line with [AST_NESTED_FUNCTIONS=]) is the block that is run if AC_COMPILE_IFELSE succeeds without the -fnested-functions gcc flag.  So we're not checking for nested functions, we're checking if nested functions fail without the flag.

Now if AC_COMPILE_IFELSE does fail we assume that it would succeed with the GCC flag.  In theory we should verify that it would work with -fnested-functions.  But that is a separate issue.


- Corey


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4370/#review14519
-----------------------------------------------------------


On Feb. 20, 2015, 9:35 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4370/
> -----------------------------------------------------------
> 
> (Updated Feb. 20, 2015, 9:35 p.m.)
> 
> 
> Review request for Asterisk Developers and Diederik de Groot.
> 
> 
> Bugs: ASTERISK-20850
>     https://issues.asterisk.org/jira/browse/ASTERISK-20850
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This is a continuation of the patch put up for review on r3488. It addresses the issues found on that review.
> 
> This patch *should* make Asterisk compile under clang. Note that compiling with --enable-dev-mode will cause Asterisk to fail to compile under clang, as it detects a number of warnings that aren't fixed under this patch.
> 
> 
> Diffs
> -----
> 
>   /branches/11/makeopts.in 432053 
>   /branches/11/main/Makefile 432053 
>   /branches/11/include/asterisk/utils.h 432053 
>   /branches/11/include/asterisk/inline_api.h 432053 
>   /branches/11/configure.ac 432053 
>   /branches/11/configure UNKNOWN 
>   /branches/11/Makefile 432053 
> 
> Diff: https://reviewboard.asterisk.org/r/4370/diff/
> 
> 
> Testing
> -------
> 
> * Compiled Asterisk with and without --enable-dev-mode using gcc. Asterisk compiles correctly.
> * Compiled Asterisk without --enable-dev-mode using clang. Asterisk compiles, links, and executes.
> 
> Note that you will need the BlocksRuntime to run Asterisk when it is compiled with clang.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150311/7d04e2bf/attachment.html>