[Ecls-list] Type propagator and "bogus" existing code

[Juan Jose Garcia-Ripoll]

On Sat, Jun 19, 2010 at 4:16 PM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

> It is valid Lisp, then error is obviously not acceptable.
> Any other form of diagnostic that leads to build error is also
> too severe.  Obviously, miscompilation is not an option.
> My question is: can ECL still generate correct codes?
>

There is no such thing as "correct" in this case, because the arguments were
declared / inferred to have one type and the function expects a different
one. Typically ECL will detect the unused branches later at an expansion or
at an optimization stage, but if not, the outcome will vary. For low safety
high speed optimization settings, ECL may decide to expand the function. In
other cases it may decide to just use an indirect call. Only the first case
might be problematic: in case ECL unboxed the declared arguments and the
optimized implementation uses low level C, the resulting expressions might
actually be invalid. I am just wondering whether this can be prevented,
perhaps by marking the C1FORM as problematic.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100619/e0a982e7/attachment.html>