Fix possible evaluation order problems.

Fix possible evaluation order problems.

We should not allow handle dereference and GC inside the same expression because order of subexpression evalution are not defined.

Committed: http://code.google.com/p/v8/source/detail?r=5509

[Vitaly Repeshko, 2010-09-21 21:19:54]

Drive by question.

http://codereview.chromium.org/3398014/diff/3001/4001
File src/api.cc (right):

http://codereview.chromium.org/3398014/diff/3001/4001#newcode774
src/api.cc:774: i::Handle<i::Object> proxy = FromCData(value);
Isn't  it true that by the time handle is created the GC has already happened
(if it was required)? Function calls/returns are sequence points.

[Erik Corry, 2010-09-23 07:53:28]

LGTM

http://codereview.chromium.org/3398014/diff/1/2
File src/bootstrapper.cc (right):

http://codereview.chromium.org/3398014/diff/1/2#newcode1420
src/bootstrapper.cc:1420: } while (false);
This semicolon should not be there.

http://codereview.chromium.org/3398014/diff/3001/4001
File src/api.cc (right):

http://codereview.chromium.org/3398014/diff/3001/4001#newcode771
src/api.cc:771: static void SetFieldWrapped(void  (T::*setter) (i::Object*,
i::WriteBarrierMode),
This doesn't lint, but presumably removing the double space would fix that.

http://codereview.chromium.org/3398014/diff/3001/4001#newcode775
src/api.cc:775: ((*a)->*setter)(*proxy, i::UPDATE_WRITE_BARRIER);
I don't like pointer-to-method, and I don't like having to write the full name
of the method at the use points.


A macro SET_FIELD_WRAPPED(obj, function, value) would work better here.

http://codereview.chromium.org/3398014/diff/3001/4002
File src/bootstrapper.cc (right):

http://codereview.chromium.org/3398014/diff/3001/4002#newcode1420
src/bootstrapper.cc:1420: } while (false);
You need to lose the semicolon here.