Sami Vaarala

If you're referring to the `--> undefined` printouts, they are simply the result of `eval()`ing the input: - https://github.com/svaarala/duktape/blob/master/extras/module-node/test.c#L86-L97 In particular, if the script being eval'd ends with `assert(...)`, assert()...

One problem with using initializer macros is that the most natural initializer would involve a type/flags field and a union of some sort for the value alternatives. But union initializers...

Having the ability to provide property attributes too (if user wants to use non-default values) would also be useful.

One option for portable initialization is to: - Use unions as the property list value type - Use named union initializers in C99 compilers, as they're quite widely supported -...

Another portable option which is a lot messier is to use a struct initializer, but share the fields so that e.g. both void and string pointers can share the same...

Here's a very basic sketch of how that union initializer/helper call model would work: - https://github.com/svaarala/duktape/compare/api-new-list-inits This is just to document what the most potential approach seems to be so...

Helper functions may be an issue for global values. Perhaps the best approach is to: - Use union initializers for C99 - Use struct initializers for non-C99 environments, with some...

@darkuranium I agree that union + struct initializer fallback seems like the best option unless someone comes up with a better idea.

I'll try to get this issue resolved for Duktape 1.5.0, so far union+struct approach (see example by @darkuranium) seems to be the most realistic option. I'll try to come up...

@darkuranium Re: macros vs. functions, I'm using union/struct initializer macros only. The helper functions are not going to be used because they don't work well for static initializers.