On Tue, Mar 22, 2016 at 6:58 AM, Adam Devita <adevita at verifeye.com> wrote:
> It may be pedantic, but VS2016 will stop complaining if you edit your
> definition of s to
> large_struct s=new large_struct(); //set s to an actual instance of
> large_struct. c people can think of s as a pointer, and in c# the
> members are set to their default values.
>
The point was, the structure had some 20 members, and 90% of the time
the conditions don't exist for it to be initialized. So rather than
initialize it 90% of the time for no use, I added checks to optimize
the object's creation.
> J Decker's point could also have been made by using int x in place of
> large_struct s . and sub x for s.x , since it is a contrived example
> anyway. The only way to use x is if another conditional on another
> variable that follows it in code and it is initialized.
>
> if one writes
> const bool arbitrary_true_false = true; //note the const as Scott
> Doctor implied, makes the error go away.
>
It's not a const though, it's a variable the changes during runtime
and allows for the creation of such an object. It's not 'contrived' it
was an example that I ran into while developing (several times in
fact).
similarly soemthing like (I haven't run it though compilers, so don't
know if this is nested enough to cause the same issue... but it's easy
to see how a compiler/error checker would similarly be confused.
void f() { int a, b;
for( a = 0; a < 2; a++ ) {
if( a == 0 ) b = 1234;
}
printf( "b is never uniniialized here : %d", b );
}
> ---------
> This discussion on the nature of undefined behaviour code is
> interesting. I don't know the reasoning, but it seems that VS6 often
> initialized things to 0xcd in debug mode and (usually) had memory
> uninitialized to 0x00 when complied in Release (perhaps 0x00 just
> happens to be what was on the stack or heap). I presume this wasn't
> just to make people suffer when things don't work the same in debug
> vs release mode.
>
> Does the tool help (in the sqlite in practice) point out things that
> could be problematic? Is it a compiler's variant of "hay, you are
> depending on implemented, not documented behaviour" ?
>
> regards,
> Adam DeVita
>
>
> On Tue, Mar 22, 2016 at 7:27 AM, Scott Doctor <scott at scottdoctor.com>
> wrote:
>>
>> It is uninitialized. you are setting an initial value within an if
>> statement. For the compiler, the code has NOT actually executed. so it does
>> not use the value of the variable arbitrary_true_false. If it was a #define
>> then it would use the value but still give an error because it is not a
>> compiler directive #if but a code if.
>>
>> The logic is that the first instance of assignment is within a conditional.
>> That is a particularly nasty kind of bug and should be reported as an error.
>> because if later you decide to change arbitrary_true_false to false, then
>> s.x would not be initialized before use. the compiler is correct to issue
>> the warning. Give s.x a value after/at initialization, but before the if
>> statement to give it a desired initial value then recompile, that should fix
>> the error.
>>
>> Compilers only set the code to initialize the variable at declaration, not
>> actually use the values during compile. If it was declared as a constant
>> using a compiler directive such as #define, then the compiler would use the
>> value in the logic and still give an error, but a different one because the
>> conditional would always evaluate true (or false depending on what it was
>> set to)
>>
>>
>> On 03/21/2016 21:31, J Decker wrote:
>>>
>>> On Mon, Mar 21, 2016 at 8:40 PM, Scott Doctor <scott at scottdoctor.com>
>>> wrote:
>>>>
>>>> you are missing
>>>>
>>>> using System;
>>>
>>> whatever. It still fails because it says the variable is
>>> uninitilalized. THe only thing that doesn't is actually running it.
>>>
>>> That same pattern not matter what the language triggers warning/error
>>> checkers
>>>>
>>>> ------------
>>>> Scott Doctor
>>>> scott at scottdoctor.com
>>>> ------------------
>>>>
>>>>
>>>> On 3/21/2016 5:21 PM, J Decker wrote:
>>>>>
>>>>> So far I just see analysis tools fail for the same sorts of valid
>>>>> code...
>>>>>
>>>>> this is a bit of C# but the same idea causes the same warnings and
>>>>> there's nothign tecniclally wrong with this.
>>>>>
>>>>>
>>>>>
>>>>> class test
>>>>> {
>>>>> struct large_struct { public int x; }
>>>>> bool arbitrary_true_false = true;
>>>>> void method()
>>>>> {
>>>>> bool initialized = false;
>>>>> large_struct s;
>>>>> if( arbitrary_true_false )
>>>>> {
>>>>> initialized = true;
>>>>> s.x = 1;
>>>>> }
>>>>> if( initialized )
>>>>> {
>>>>> Console.WriteLine( "this fails(during compile) as
>>>>> uninitialized: {0}", s.x );
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> On Mon, Mar 21, 2016 at 4:35 PM, James K. Lowden
>>>>> <jklowden at schemamania.org> wrote:
>>>>>>
>>>>>> On Mon, 21 Mar 2016 13:48:06 -0700
>>>>>> Scott Perry <numist at apple.com> wrote:
>>>>>>
>>>>>>> Compilers allow you to choose your standard; --std=c11 means
>>>>>>> something very specific (and unchanging)
>>>>>>
>>>>>> They do. And that covers what the standard covers. The standard also
>>>>>> has limits. It includes constructs that are syntactically permitted
>>>>>> but whose behavior is left undefined, known by the scarred as "UB" for
>>>>>> "undefined behavior". An example from Clang's discussion is
>>>>>>
>>>>>> int i = 10 << 31;
>>>>>>
>>>>>> The standard says << is a shift operator. It places no limit on the
>>>>>> number of bits to be shifted. If that number is so large that the
>>>>>> product cannot be represented by the assigned variable, that is *not*
>>>>>> an error. The standard allows the compiler to do anything or nothing
>>>>>> with it. As you may imagine, the varieties of anything and nothing are
>>>>>> many.
>>>>>>
>>>>>> Compiler writers are well aware that "nothing" is faster done than
>>>>>> "something". Over time, they have gotten more aggressive in simply
>>>>>> deleting UB code. As a consequence, programmers who thought they wrote
>>>>>> standards-conforming code get burned when they upgrade/change
>>>>>> compilers. Mysterious and sometimes subtle errors are introduced by
>>>>>> the compiler for the user's benefit.
>>>>>>
>>>>>> Your googlefu will turn up lots of discussion. One I liked that wasn't
>>>>>> on Page 1:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://blog.frama-c.com/index.php?post/2013/10/09/Overflow-float-integer
>>>>>>
>>>>>> --jkl
>>>>>> _______________________________________________
>>>>>> sqlite-users mailing list
>>>>>> sqlite-users at mailinglists.sqlite.org
>>>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>>>
>>>>> _______________________________________________
>>>>> sqlite-users mailing list
>>>>> sqlite-users at mailinglists.sqlite.org
>>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>>>
>>>>>
>>>> _______________________________________________
>>>> sqlite-users mailing list
>>>> sqlite-users at mailinglists.sqlite.org
>>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>> _______________________________________________
>>> sqlite-users mailing list
>>> sqlite-users at mailinglists.sqlite.org
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>>
>>
>> --
>> ---------------------
>> Scott Doctor
>> scott at scottdoctor.com
>>
>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users at mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> --
> --------------
> VerifEye Technologies Inc.
> 151 Whitehall Dr. Unit 2
> Markham, ON
> L3R 9T1
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
