Hi, Kassen, I noticed this bug when I wrote about 20 lines of code in a row, (you know, I'm a programmer myself :)) and then I tried to run it, which caused ChucK to crash. I had to undo the changes step-by-step until ChucK worked again. I'm a C programmer, and in C, I often write an infinite loop like this: for(;;) {} I prefer for() loops to while() loops, because for loops have the ability to step the cycle variable even if you put a continue; in them. And programmers have the ability to forget to step variables in a while() loop. :) Regards, Szilveszter aka Hillaby Kassen escribió:

Hi Szilveszter,

I also checked out the source code and made a change which made this loop work: at chuck_dev\v2\chuck_type.cpp:873:

I enclosed the switch() block in a conditional:

if (stmt->c2) { ... }

Now it seems to work.

First; great job on fixing this crash, that's the spirit!

I do have a question though. It seems that you are implying here that a empty condition now evaluates to true (or at least not false). Assuming we adopt this fix; would this now be true in the general case, or just for "for" loops? Are there precedents on empty conditions evaluating to true? Just curious; crash prevention is the main thing here, I don't see much practical use in empty "for" loops anyway, because "while(1)" is just as one character more than "for(;;)" and a lot more readable.

Yours, Kas. ------------------------------------------------------------------------

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

Hi Kassen, I would not go scientific here... :) I just wrote down a line of code which I expected to work... However, I've never written down anything like: if() {} or while() {} which I suspect would give a C compiler error. My point is that the first and the third part of the for() statement can be omitted as for now (in ChucK). So I don't see a point why the second one shouldn't work the same way. Regards, Szilveszter aka Hillaby Kassen escribió:

Hey Szilveszter!

(you know, I'm a programmer myself :))

You wouldn't say! ;-)

I'm a C programmer, and in C, I often write an infinite loop like this: for(;;) {}

I prefer for() loops to while() loops, because for loops have the ability to step the cycle variable even if you put a continue; in them.

Ok, I see. This makes sense and it makes sense to follow C. I'm going to adopt that trick as well, though for infinite loops that will never break or continue I'll stick to "while(true)" as that's still more readable to me.

So, to be perfectly clear, (as a programmer I like to try and see the structure,) this particular case of a condition is a exception in that it can now be empty, with empty being seen as "not explicitly false and hence true" and this does not hold true for other conditions such as -say- empty clauses in "if" and "while" loops?

Thanks, Kas. ------------------------------------------------------------------------

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

Hi Kassen, Kassen escribió:

Most important to me is that I don't think that anything that comes through the parser should crash the whole VM. To be perfectly clear; I don't disagree with anything here,

Well, I think an error message saying that the conditional part is empty would do as well :). The crash is not too elegant. Regards, Szilveszter aka Hillaby

Hi Ge! Thanks for the fix, it works! Regards, Szilveszter (aka Hillaby) Ge Wang escribió:

Hi Szilveszter and Kassen!

Thanks for the discussion, and thanks to Szilveszter for the report and the fix (it's right on)! I've included the fix into the source, with a minor tweak - I think for now, we are going to disallow empty for conditions, and will require an explicit true. For example:

for( ; ; ) { /*...*/ }

now gets the follow compiler error:

[foo.ck]:line(1): empty for loop condition... [foo.ck]:line(1): ...(note: explicitly use 'true' if it's the intent) [foo.ck]:line(1): ...(e.g., 'for( ; true; ){ /*...*/ }')

This will still leave the possibility of for( ; ; ) to work in the future, but it seems harder going the other way...

I hope this helps and thanks again for the fix!

All the best, Ge!

~~~ Ge Wang Assistant Professor Center for Computer Research in Music and Acoustics (CCRMA) Stanford University http://ccrma.stanford.edu/~ge/ ~ Co-founder, CTO, Chief Creative Officer Smule http://www.smule.com/ | http://twitter.com/gewang ~~~

On Fri, 23 Oct 2009, Kassen wrote:

...

Szilveszter

I would not go scientific here... :) I just wrote down a line of code which I expected to work... However, I've never written down anything like:

if() {} or while() {}

Erm, no. :-)

which I suspect would give a C compiler error.

I should hope so, yes. If I were a parser I'd go on strike over that.

My point is that the first and the third part of the for() statement can be omitted as for now (in ChucK). So I don't see a point why the second one shouldn't work the same way.

The one perspective I could see is that the first and third are actions, and omiting those seems quite natural if we need no action to be taken. The second is a condition and it's less intuitively clear what omiting it should mean. Borrowing from C seems quite natural.

I seem to remember there were previous issues with more exotic "for" loops in ChucK, btw. Previously there was a issue with stuffing more than one thing (some of which could be commands that need not evaluate to true or false, as long as the last one did), that would also crash. My memory is hazy on this as I didn't see the use but now I do, it's probably to get those out of the scope of any "continue" commands we might use.

Most important to me is that I don't think that anything that comes through the parser should crash the whole VM. To be perfectly clear; I don't disagree with anything here, I'm just trying to see whether this is or should be part of a larger structure that I should understand. I know I can sometimes come across like I'm arguing when doing that. I think that urge is satisfied for now :-).

Thanks again, Kas.

------------------------------------------------------------------------

_______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev