On 22/07/2015 13:14, Jeffrey Walton wrote:
> On Wed, Jul 22, 2015 at 6:40 AM, Jakob Bohm <jb-openssl at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150722/c4a417fd/attachment.html>
