[chuck-users] dynamic array crashes for "int ar[]" but not "int ar[0]"

George Locke george.locke.maxmsp at gmail.com
Sat Jul 28 12:09:50 EDT 2012


Hey Kassen,

Thanks for looking into it.  I'm picking up what you're putting down,
pretty much.  int ar[] is a reference to nothing, like a null pointer, so
asking the VM to call a method is accessing uninitialized memory, like a
seg fault.  I think I shouldn't have said "crashes" when what I meant was,
the thread dies and throws an exception, not that the audicle executable
nor the VM breaks.  It's a run-time error and not a syntax error; that's
what I had in mind.

I am glad to understand ChucK a little better.

Thanks again,
George

On Sat, Jul 28, 2012 at 9:42 AM, Kassen <signal.automatique at gmail.com>wrote:

> > Hi,
>
> Hey George!
>
> >
> > array.size(int) and the '<<' operator are crashing miniAudicle (version
> > 0.2.0, on Windows 7 pro).  (functionality added to chuck in 1.2.1.2,
> > http://chuck.cs.princeton.edu/release/VERSIONS ).  miniAudicle tells me
> it's
> > running chuck 1.2.1.2.
>
> Check.
>
>
> > playing around a bit, I now find that if I follow what the example
> > array_dynamic.ck says and replace "int ar[]" with "int ar[0]", then the
> code
> > works.  I guess that means this isn't a bug but a meaningful difference
> > between ar[] and ar[0]?  In any case, I might amend the array_dynamic.ckto
> > say something like
> > "float argh[0]; // must set argh[0] and not argh[]"
> >
>
> Well, if ChucK crashes it's a bug; ChucK should not crash if you make
> a syntax error, it should catch it at parsing and inform you. It is
> also not unambiguously clear to me that what you tried is actually a
> error, IMHO this should be fair game, it looks natural and expressive.
> I can tell you what goes wrong though.
>
> "int ar[]" creates a reference to a array but does not instantiate it.
> You'd use it in a context like this;
> [1, 2, 3] @=> int ar[];
>
> Evidently ar.size(int a) should instantiate the new array entries if a
> is larger than the old size, which it'll always be for uninstantiated
> arrays so I find what you tried defensible, but ChucK is also a bit
> right to complain about a null-pointer as the reference doesn't point
> to anything yet at that point. Syntactically it seems a bit awkward,
> compared to the rest of ChucK where we don't need to care about memory
> management, though it might also have uses where this kind of explicit
> control is useful.
>
> I hope that clarifies things a bit? If all of this sounded like
> abracadabra; just use the one that works, that's what this comes down
> to :-)
>
> Yours,
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20120728/016d3e59/attachment.html>


More information about the chuck-users mailing list