[Ecls-list] Problems with clines

[Juan Jose Garcia-Ripoll]

2007/8/19, Steve Smith <tarka at internode.on.net>:
> Can someone tell me what is wrong with the following:
> [...]
> Compiling this fails with errors, as all the 'clines' code is placed
> into the header rather than inline.  Is this deliberate?

Yes. c-lines are only for include statements, defining macros, static
variables and so on. All real code must go in c-inline. This makes
send, doesn't it? Otherwise, what would you do with a #include
statement inside a function? The compiler is not so clever as to
understand what is in the C lines!

> Converting the clines to c-inline fixes this issue but raises another
> one; the resulting C source ends up like:
>     static cl_object L1test_fun()
>     { VT2 VLEX2 CLSR2
>        cl_object value0;
>        {
>     TTL:
>           fd_set read_fds, write_fds;
>           FD_ZERO(&read_fds);
>           FD_ZERO(&write_fds);
>
>           FD_SET(((int)0), &read_fds);
>           value0=Cnil; NVALUES=1;
>           return value0;
>        }
>     }

This simply signals a deeper problem in your code. c-inline code must
be self-contained, autonomous. You cannot create variables in one
c-inline that you later use in another c-inline because you cannot
assume anything about the structure of the C code that is to be
generated. Remember that this is not a 1-1 translation, but rather a
compiler that uses C as backend and is allowed to make code
transformations.

If you need to have such things, then use lisp foreign variables. Or
static variables. Or in the case you present above, just put the file
descriptors where they are going to be used and execute de lisp code
before that and pass the values you need as parameters.

Cheers,

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com