<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<title></title>
<style type="text/css">code{white-space: pre;}</style>
</head>
<body>
<p>Hi Rémi,</p>
<p>On 2017-02-26 22:27, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> static
-__attribute__((unused))
-__attribute__((noinline))
-__attribute__((error("sorry, cannot sleep for such short a time")))</code></pre>
</blockquote>
<pre><code> The noinline attribute is required to inhibit optimization and let this
function do its magic. And then the unused attribute is required to avoid one
warning for each compilation. Finally the error attribute is the very essence
of the function.</code></pre>
</blockquote>
<p>To be pedantic: the usage of <code>__attribute__((noinline))</code> does not make much sense together with <code>__attribute__((error("")))</code> as usage of the function shall result in a diagnostic, and there is therefor nothing to inline nor optimized away.</p>
<p>If you are saying that <code>noinline</code> is a backup if <code>error</code> is ignored on a, what you considers <em>“non <code>__GNUC__</code> compliant”</em>, compiler; I do not see how that plays very well with the previously stated opinions (and would like to ask for a clarification).</p>
<ul>
<li>https://mailman.videolan.org/pipermail/vlc-devel/2017-February/111763.html</li>
</ul>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> So overall, I would say that all three attributes are nonoptional. Even if
this header were not part of the public out-of-tree set, I would not really
get the sense of this patch.</code></pre>
</blockquote>
<p>Yes, the introduction of that function does only make sense if the mentioned attributes are supported by the underlying implementation; something I was about to address in a follow-up patch before you made your replies (but you <em>“nacked”</em> me before I had a chance to, and now it does not to matter).</p>
<p>Best Regards,<br />
Filip Roséen</p>
</body>
</html>