[plt-scheme] Output from compile-extension-parts-to-c

(Sorry - I'm replying about a month late. I missed the message when it
was first sent, and only discovered it now while cleaning out my
mailbox.)

At Thu, 12 Jun 2003 11:18:24 -0700 (PDT), Ulf Leopold wrote:
> Since I'm embedding MzScheme
> in my application I have to explicitly initialize the
> extension. For that I use the following code that I
> borrowed from "cmdline.inc".
> 
>  {
>      Scheme_Object *f, *a[1];
>      f = scheme_initialize(e);
>      a[0] = scheme_true;
>      f = _scheme_apply_multi(f, 1, a);
>      if (SAME_OBJ(f, SCHEME_MULTIPLE_VALUES) &&
>          (scheme_multiple_count == 2))
>      {
>          f = scheme_multiple_array[0];
>          _scheme_apply(f, 0, NULL);
>      }
>  }
> 
> This works well under linux. But in my windows version
> I get a segmentation fault when executing the test
> "(scheme_multiple_count == 2)" in the if-statement.
> 
> Since I'm cross compiling the windows version from
> linux, I was wondering if perhaps
> "compile-extension-parts-to-c" produce different
> c-files when run under linux, than when run under
> windows. Is this the case? 

No. The generated C code is the same for all platforms.

> I was unable to test this
> because even under linux
> "compile-extension-parts-to-c" produces a different
> c-file each time I run it. Is this due to the compiler
> using the "random" function (it seems to use the same
> seed though) or is it somehow linked to the scheme
> macro system? Can it be made to produce the exact same
> output from one run to another?

Probably you're seeing a `gensym' effect, though offhand I'm not sure
how you'd get different results for different runs.

> I have a feeling the segmentation fault may be due to
> something else, but it would be nice to rule out this
> uncertainty. (By the way, the cross compiled windows
> executable worked well as long as I didn't compile the
> scheme code to C.)

The `scheme_multiple_count' name macro-expands to a dereference of
scheme_current_thread, so that's how it could segfault. Then the
question is how `scheme_current_thread' could have a bad address.

Assuming that this is still a problem... 

Do you call scheme_set_stack_base() with a non-zero second argument and
explicitly register the stack base and statics? If not, maybe doing so
will help.

Matthew