<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 22/07/2015 13:14, Jeffrey Walton
wrote:<br>
</div>
<blockquote
cite="mid:CAH8yC8m_iGw_g_6wqMwQYV207CW5nZXu4-QCOjfCL=WJ_PQVmg@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Jul 22, 2015 at 6:40 AM, Jakob Bohm <a class="moz-txt-link-rfc2396E" href="mailto:jb-openssl@wisemo.com"><jb-openssl@wisemo.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 22/07/2015 01:21, Jeffrey Walton wrote:
For the stragglers, I don't think its a stretch to ask C99 in 2015.
Visual Studio is often used on Windows, and it is not C99.
Oh my, I was not aware it was still struggling for C99 :) I guess
Microsoft is still putting their energies into the "one-size, tablet
interface known as Windows 8, fits all, even on desktops without a
touchscreen".
On the good side, MSVC does not need to be 100% compliant. It just
needs to support initialization at time of declaration. That
particular feature works.
Isn't that a C89 (or maybe even K&R) feature?
</pre>
</blockquote>
<pre wrap="">
I thought that was C99. I think Ben Laurie even corrected me with some
OpenSSL sample code because I initialized a variable without using
-std=c99.
</pre>
</blockquote>
<tt>There is a C99 feature backported from C++: Allow <br>
declarations after/between statements, thus allowing <br>
unconditional initialization formulas to be used even <br>
if code is needed before them.<br>
<br>
E.g.<br>
<br>
int foo61(void)<br>
{<br>
int a = 1;<br>
int b = 5;<br>
do {<br>
a *= b;<br>
} while (--b);<br>
int c = a / 2; // C99/C++ only<br>
<br>
return c + 1;<br>
}<br>
<br>
<br>
</tt>
<blockquote
cite="mid:CAH8yC8m_iGw_g_6wqMwQYV207CW5nZXu4-QCOjfCL=WJ_PQVmg@mail.gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">There is another problem though: Blindly initializing
every variable with dummy values (because the correct
value comes from one or more if() branches), only
achieves two things, both bad:
- It hides correct warnings in case one of those if()
branches forgets to set the variable, before it is
read.
- It potentially confuses less-than-halting-problem-
solving optimizers to needlessly generate code that
allocates and initializes the variable because they
cannot detect (within their compile time resource
limits) that the dummy value is (hopefully) never
used.
The second problem is almost guaranteed to happen on
any compiler/option combination that would otherwise
falsely warn about the variable being maybe-
uninitialized. This is because most compilers
generate that warning as a side effect of the
optimizer trying to figure out if the garbage or
dummy value will be used by the code.
</pre>
</blockquote>
<pre wrap="">What, exactly is the problem? The program is in a known state. As far
as I know, that's the best state to be in.</pre>
</blockquote>
<tt>In the first case, the program is in a wrong state, <br>
and no tool will tell you about it. Silently producing <br>
a wrong result is quite unpleasant.<br>
<br>
In the second case we have inefficient code.<br>
<br>
And if the compiler *can* detect the situation correctly, <br>
and the code *is* correct without the extra initialization, <br>
the compiler is likely to emit a warning that variable is <br>
assigned a value which is never used.<br>
<br>
So if the goal is to avoid warnings, you can't win anyway.<br>
<br>
If as in the case under discussion, the value is set and <br>
used only under a (common) condition, one may consider a <br>
structural change so the condition is checked only once, <br>
then move the variable inside that conditional block. On <br>
pipelined processors, this may even result in faster code, <br>
though it will be larger, this however depends on a closer <br>
analysis of the particular code.<br>
<br>
<br>
</tt>
<blockquote
cite="mid:CAH8yC8m_iGw_g_6wqMwQYV207CW5nZXu4-QCOjfCL=WJ_PQVmg@mail.gmail.com"
type="cite">
<pre wrap="">
And that's why managed languages like Java and .Net are so popular.
When a variable is declared, it gets placed in a known state
immediately. It relieves the programmer of remembering pesky details
like, "remember to initialize your variables to a known state".
</pre>
</blockquote>
<tt>But it also makes it harder to auto-detect bugs where a <br>
variable is left in that </tt><tt>default state when it should <br>
have been in a different state. In fact for languages <br>
without implicit initialization, there are often debug <br>
tools that can set the variables to a known impossible <br>
value and report if those values are ever used. <br>
Typical choices include 0xBAADF00D (where 32 bit <br>
pointers are restricted to the range 0x00001000 to <br>
0x7fffFFFF) etc.<br>
<br>
<br>
</tt>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>