really weird problem.

[wtf]

OK this is really weird.

I have encountered a runtime error and isolated it to a line that has not yet been executed.

I won't post all of my code, although I have been unable to duplicate it in a test program. i.e. the line of code in question will compile and run in a program by it self, but throw it into my program and it goes haywire.

    bool dew = true, *d;
    while(1)
        {
            static int count = 0;
            cin.clear(); clearcin(cin);
            cout << "count = " << ++count << endl; 
            //exit(13);
            if(*d = &dew && (*(char *)d)-- )

                {//exit(123);
                    dewsomestuff();
                    someotherstuff();
                }
            //exit(14); 

            //some other stuff goes here
            for (int i = 0; i == 0; ++i)
                {
                    ;
                    //some relevant or irrelevant code coes here
                }
            //a few more tidbits



        }//end of while loop 

If I comment out the line exit(13) it will exit at that point.
Otherwise I get an error program.exe ha detectado un problema y debe cerrarse.
and returns Process returned -1073741819 (0xC0000005) execution time : 1.203 s. and count never makes it past

count = 1

However if I change for (int i = 0; i == 0; ++i) to for (;;) or comment it out completely, the program will run as expected.

Keep the for loop as it is, the program will not reach exit(14); or exit(123);

How could the for loop be causing my program to barf?

[rocketboy9000]

The for loop will only ever execute once. On the second iteration, i is 1, so i == 0 is false.

[wtf]

I know that rocketboy9000.

For your infomation I had the for loop to create a natural scope only, I had been having problems getting it to work with just {} so I made the braces into a for loop that would only execute 1 time.

[rocketboy9000]

Copy your program, then cut away as much as possible while retaining the problem.

[coder777]

What are you doing on line 8. 'd' is an uninitialized pointer to a bool. You dereferenced that uninitialized pointer. Assigns a pointer to a bool (which resides beyond nirvana). Then you cast that still uninitialized pointer to bool to an uninitialized pointer to char and decrements it. And for unknown reason you connect it with &&.

If that doesn't deserve a crash I don't know what deserves a crash

program.exe ha detectado un problema y debe cerrarse.

You can't say it better

[wtf]

So what I want is to have:

d = new bool; *d = dew;

Somewhere before the while loop?

It seems as if even better if I replace line 8 with:

if( dew && ( (*(char *) &dew)--) )

Does that line of code avoid the uninitialized pointer stuffs? It seems to avoid the unatural program termination, but am I opening myself up to further trouble down the road? My reasoning for doing this is code obfuscation, but mainly just for fun/I was bored... as I do not intend to release my source code. Would it be better to stick with something less cool like if (dew){dew = false; cout << "Repeat?\n"; cin >> dew;} or something like that?

My intention is to execute a couple of functions (called from within the body of the if(dew) statement), by default only on the very first iteration of the loop, and then sporadically as well, but only upon user request. It seemed natural to use a bool and decrement the bool on the first read, that is what the && is for, so that after the first pass it will evaluate dew to false and ignore the second condition. However my compiler wouldn't let me post decrement a bool, so played around with casting it as an int and finally ne555 reccomended if( (*(char *) &dew)-- )

Is this alright?

And you talk about accessing variables in nirvana. Is that even possible? How would I do that? Is that what is causing code (line 17) that has not been executed to screw with the system? Maybe one of the bools in Nirvana has been observing the for loop on line 17 and has a fancy for it, so its trying to abduct her to the nether world? Could I somehow excorcize the for loop from the evil bools to prevent this from happening?

[wtf]

bump

[rocketboy9000]

You can't decrement a bool! Just use an integer.

[coder777]

wtf wrote:

Would it be better to stick with something less cool like if (dew){dew = false; cout << "Repeat?\n"; cin >> dew;}

Of course it would. Fancy code often leads to exorcism (aka debugging) and curses (from other programmer). How cool is a code when you need a whole block of text to explain it? I find self explanation much cooler.


The evil in your code is the cast. If the compiler tells not to do it then don't do it. At the end you trick yourself.

And your program usually meets the netherworld with uninitialized variables.

[Athar]

This results in just plain undefined behavior: (*(char *)d)--
A correct version of this is: if (dew && !(dew=false))
By the way, there's nothing cool about incorrect or cryptic code, much less incorrect and cryptic code, so
if (dew){dew = false; ... is by far the best solution.

[wtf]

ok athar I guess I'm going with

if (dew && !(dew= false))

Unless someone has a decrementable bool class they'd be willing to share with me?

[Disch]

what's the point of decrementing a bool?

Also +500 to Athar:

if (dew){dew = false; ... <-- This really is the best way to do it. You're making your code a lot more obfuscated than it has to be.

[wtf]

aight disch, not if I declared dew as an int, in which case decrementing would still be allowed and if (dew && dew--) would win because it just feels right.

and another thing: what the point of decrementing a bool is is if you can cast an int as bool or a bool as an int you ought to be able to do the same things with them, such as incrementing and decrementing. Why wouldn't you be able to decrement a bool? Don't say because it wouldn't make any sense because it is already defined. False = 0;

[Disch]

if (dew && dew--) would win because it just feels right.

This shouldn't win ever -- and it certainly shouldn't feel right. It's very confusing and counterintuitive.

The parethesis part following an if statement is for a conditional statement. if that conditional statement is true, the {body} of the block following the condition is executed. it's a very simple structure:

if( some_condition )
{
   Code_to_execute_if_condition_is_true();
}

Now ask yourself this: Is dew-- part of the condition? No? Then it doesn't belong in the parenthesis. It's that simple.

Finding a clever way to work part of the executed code into the condition isn't clever, it's just code obfuscation. It does nothing but introduce possible bugs and make your code harder to follow. You really shouldn't be doing this kind of thing ever.

Why wouldn't you be able to decrement a bool?

Because conceptually it doesn't make any sense. Although I see your point -- and it does logically make sense since true and false are defined in C++ to be 1 and 0 respectively.

So yeah I halfway agree with you here so I won't get into it. However....

What I will say is that if the goal here is to make dew false... then do the obvious.

dew = false is obvious. Your intent is clear. dew-- isn't as obvious becaue the intent depends on the previous state of dew.

No offense intended, but I think you need to take some lessons on code clarity. You seem to drift towards weird things that makes your code crazy hard to follow. The fact that you tried to cast pointer types so that you could decrement instead of just doing "= false" is kind of mind blowing.

[rocketboy9000]

The best way to obfuscate code is simple: Compile it.

[wtf]

Now ask yourself this: Is dew-- part of the condition? No? Then it doesn't belong in the parenthesis. It's that simple.

Ok. I can kind of see your point. I shouldn't risk introducing bugs just for the sake of code obfuscation. But I still think that the c++ standard should make things more clear, for the likes of those like me, those still learning that don't know any better than to trust a compiler. After all if it compiles, and does what you expect it to based on basic rules of syntax, you should be able to be reasonably well assured that the compiler isn't just relying on 'un-defined' behavior.

lol... I'm kind of chuckling right now as I'm typing this. I just realized right now that the compiler had tried to warn me didn't it? It wouldn't let me decrement a bool, but I persisted and casted it as an int. Credit should be given to ne555 for the final verson of decrementing a dereferenced bool reference cast as a char pointer. He's a genius. It's a pity that the standard neither allows or disallows this sort of thing, and I think its deplorable that 'undefined behavior' can cause a line of otherwise perfectly legal code to cause a segmentation fault.

For the sake of newbies everywhere... Writing code (especially code that confines to basic 'principals' (such as those whose intrincinties which newbies shouldn't be expected to know ) ) should never 'unexpectedly' cross an invisible threshold and grant to the compiler free license to do what it wishes with so called 'undefined behavior'.


Edit: I can't find the correct spelling of the word in bold, someone help me think of the right word.

[filipe]

intricacies