On 11/19/13 19:13 , Eliot Miranda wrote:
It's not clear to me how an arbitrary interpretation mechanismI would argue that in fact the best way to deal with differing UNIX
implementations is this approach. For example, ioctl defines, socket
constant defines, struct layouts, etc, etc all differ markedly between
UNIX implementations, and hence one easy way to extract exact
information is to generate, compile and either run or load a program
that reveals the implementation details.
would reveal what function to call to invoke e.g. malloc(), assuming that's all there is to it. The mechanism would have to deal with arbitrary macro code expansion, arbitrary code without source code provided by the compiler itself, and on some platforms such as OS X the behavior of malloc() could depend on the value of environment variables at the time the binary is loaded (as opposed to the time when the interpretation mechanism looks at said variables). Similarly, it's unclear what that interpretation mechanism would do in the general presence of things like
#if defined(FOO)
...
#endif
To me, avoiding writing a few lines of C does not justify the effort of correctly rewriting and maintaining (parts of) a C compiler in Smalltalk.
Generally, I agree that one could carefully and consciously write comparatively small primitives and/or plugins. Then, one could compile those with a C compiler in a compilation environment compatible with that of the VM. And then, one could call those primitives and/or plugins from the image with the expectation (within reason) that they should work.