[Vm-dev] debugging the garbage collector

[Noah Evans]

Didn't the ARM have a problem with int and void main? IIRC you just
end up with whatever was last on the stack or in a register, as the
compiler just avoids pushing on the stack or putting return values in
registers for void functions.

You don't really need to sed. Just redefine the interpreterProxy
returns to void and recompile statically. If the result of is being
used as an l-value anywhere the compiler should throw an error. In the
versions of the VM I was using this redefinition never caused any
trouble.

Noah


On Sat, Feb 16, 2013 at 1:56 AM, tim Rowledge <tim at rowledge.org> wrote:
>
>
> On 15-02-2013, at 4:01 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> Right.  But the change in signature won't break anything because those
>> return values are not used.  Right?
>
>
> If a function is implemented as void foo() would there be any realistic chance that a C compiler would make it return any faintly reliable value?  I'd hope not but maybe there is some traditional result stuck in there. If there *isn't* then anyone that tried to rely upon an incorrect declaration giving them a result should surely get some very odd responses. I suppose on an ARM APCS-C compliant compiler you'd get whatever was in the R0 register at the end of the called code.
>
> I guess a serious sed-warrior could work magic to scan all the code to find any places where something called via interpreterProxy-> seemed to be expected to provide a result. Not me; I can spell sed on a good day and that's about it.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Beware of programmers who carry screwdrivers.
>
>