Re: [cc65] bug report: pass-by-value of structs destroys stack

From: Greg King <gngking1erols.com>
Date: 2005-12-07 09:26:57
From: Sidney Cadot; on November 29, 2005, at 04:56 PM -0500
>
> Passing a struct as a function parameter destroys the stack.

From: Ullrich von Bassewitz; on November 30, 2005, at 03:42 AM -0500
>
> On Wed, Nov 30, 2005 at 09:11:41AM +0100, Groepaz wrote:
> > Is it really that much of a problem to make this work?
> > Uhm ... not that I would ever use or even need it; but anyway, :)
> > the compiler has reached an amazing level of standard compliance
> > already, would be pretty cool to get rid of the remaining few bits. :=P
>
> Adding the capability to pass structs is not too much work.
> Returning structs by value is more work.

Here is a bit of useless trivia.  A work-around lets Sidney's example work
properly with cc65:

#include <stdio.h>

struct TestStruct {
    int a;
    int b;
    };

static void testfunc(struct TestStruct ts) {
    printf("ts.a = %d, ts.b = %d\n", ts.a, ts.b);
    }

static struct TestStruct tm;

int main(void) {
    int x = 1;

    tm.a = 2;
    tm.b = 3;

    /* Fake a testfunc(tm) call. */
    {
        struct TestStruct _temp;
        _temp = tm;
        ((void (*)(void))testfunc)();
        goto skip_stack_pop;
        }
  skip_stack_pop:

    printf("x = %d\n", x);

    return 0;
    }

I call it "useless trivia" because the pass-struct-by-value feature is not
worth the trouble of writing that work-around.  But, it does show how easy,
as Uz said, it would be to implement that feature in the compiler.

--------
Hey Uz, when I lengthen the structure, to force "_temp = tm;" to do a
memcpy(), the first argument is wrong!  It is _temp's first word, instead
of its address.  I vaguely recall seeing that bug before, so I think that
it is in version 2.11.0 of cc65.
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Wed Dec 7 13:53:44 2005

This archive was generated by hypermail 2.1.8 : 2005-12-07 13:53:46 CET