[squeak-dev] Loading FFI is broken

Igor Stasenko siguctua at gmail.com
Wed Nov 20 14:07:04 UTC 2013


On 20 November 2013 04:57, Andres Valloud <avalloud at smalltalk.comcastbiz.net
> wrote:

> On 11/19/13 19:13 , Eliot Miranda wrote:
>
>> I 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.
>>
>
> It's not clear to me how an arbitrary interpretation mechanism 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.
>
>
But you forgot to mention, that while writing plugin, or trying to
dynamically link with some external library,
 an author must deal with tons of those #ifdefs as well..

IMO, macros is the worst thing invented for C.
Having 10+ years of Pascal experience, i cannot really understand why it
left behind by industry: 10/100 times faster compilation times, no crazy
modularity problems,
same (or even better code performance), but what's most important is that
you get what you see in code.

-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131120/15165a19/attachment.htm


More information about the Squeak-dev mailing list