On 22/07/2015 13:14, Jeffrey Walton wrote:
On Wed, Jul 22, 2015 at 6:40 AM, Jakob Bohm <jb-open...@wisemo.com> wrote:
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?
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.
There is a C99 feature backported from C++: Allow
declarations after/between statements, thus allowing
unconditional initialization formulas to be used even
if code is needed before them.
E.g.
int foo61(void)
{
int a = 1;
int b = 5;
do {
a *= b;
} while (--b);
int c = a / 2; // C99/C++ only
return c + 1;
}
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.
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.
In the first case, the program is in a wrong state,
and no tool will tell you about it. Silently producing
a wrong result is quite unpleasant.
In the second case we have inefficient code.
And if the compiler *can* detect the situation correctly,
and the code *is* correct without the extra initialization,
the compiler is likely to emit a warning that variable is
assigned a value which is never used.
So if the goal is to avoid warnings, you can't win anyway.
If as in the case under discussion, the value is set and
used only under a (common) condition, one may consider a
structural change so the condition is checked only once,
then move the variable inside that conditional block. On
pipelined processors, this may even result in faster code,
though it will be larger, this however depends on a closer
analysis of the particular code.
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".
But it also makes it harder to auto-detect bugs where a
variable is left in that default state when it should
have been in a different state. In fact for languages
without implicit initialization, there are often debug
tools that can set the variables to a known impossible
value and report if those values are ever used.
Typical choices include 0xBAADF00D (where 32 bit
pointers are restricted to the range 0x00001000 to
0x7fffFFFF) etc.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
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
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
