On 7/22/05, Daniel B. Faken <[EMAIL PROTECTED]> wrote: > > OK. > From what I see in chicken.h, we have: > # define C_alloca alloca > #define C_alloc(n) ((C_word *)C_alloca((n) * sizeof(C_word))) > > And as I undestand, alloca() is the same as allocating things on the stack > directly, via C variable declarations. > So does this mean instead of (for example): > C_word *data = C_alloc(N*C_SIZEOF_FLONUM); > C_word one = C_flonum(&data, 1.0); > C_word two = C_flonum(&data, 2.0); > C_word three = C_flonum(&data, 3.0); > etc. > I could do > C_word realdata[N*C_SIZEOF_FLONUM]; > C_word *data = realdata; > C_word one = C_flonum(&data, 1.0); > C_word two = C_flonum(&data, 2.0); > etc. > ??
Yes, that's fine. CHICKEN_invoke takes the current stack-pointer to set global stack-low- and high-marks, but from a quick skim of the sources this shouldn't be a problem in this case (since your allocated data is below the "low" mark). > > That is to say: > * is C_alloc() just a convenient way of avoiding getting the compiler to > understand &realdata (above) as a pointer-to-a-pointer? > (not sure if this is an ANSI-C issue - just know my compiler thought > &realdata was a pointer-to-a-C_word). Yes. > * are the issues of when to use C_alloc()-ated data identical to those > for the storing of data in the C stack? Yes. > Maybe this should be obvious.. but the documentation for C_pair(), > C_list(), etc. saying "ptr should be the address of an allocation pointer > created with C_alloc" made it seem like it was doing something special > (beyond what just declaring the memory in a C local-variable would do). > If not, maybe this could be clarified in the documentation. > Will do. Thanks for the tip! cheers, felix _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users