Review Request: New KDE Macro for to wrap the noreturn attribute

[Albert Astals Cid]

> On Feb. 13, 2012, 11:30 a.m., David Faure wrote:
> > Out of curiosity, if the method returns void anyway, why is this attribute necessary? It's not like the the compiler is going to warn about the lack of a return value...
> 
> Allen Winter wrote:
>     From the GNU Compiler documentation: "The noreturn keyword tells the compiler to assume that fatal cannot return. It can then optimize without regard to what would happen if fatal ever did return. This makes slightly better code. More importantly, it helps avoid spurious warnings of uninitialized variables."
>     
>     From my point-of-view, I just want something that can shutup compiler warnings
> 
> Allen Winter wrote:
>     ping?

It is a very niche use case, but probably makes sense to have, though you'd have to commit it carefully so that it goes into 4.9 given that we don't have a proper 4.9 branch, no?


- Albert


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103832/#review10589
-----------------------------------------------------------


On Jan. 31, 2012, 8:58 p.m., Allen Winter wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103832/
> -----------------------------------------------------------
> 
> (Updated Jan. 31, 2012, 8:58 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> -------
> 
> This diff adds a new macro KDE_NO_RETURN that wraps the noreturn attribute which is enabled differently based on the compiler.
> 
> 
> Diffs
> -----
> 
>   kdemacros.h.cmake b93242c 
> 
> Diff: http://git.reviewboard.kde.org/r/103832/diff/
> 
> 
> Testing
> -------
> 
> did a test compile
> 
> 
> Thanks,
> 
> Allen Winter
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120426/b35b849e/attachment.htm>