Re: [PATCH] Fix #1665 by blocking direct calls to externally inlineable procedures

[megane]

Peter Bex <address@hidden> writes:

> On Wed, Feb 12, 2020 at 06:18:51PM +0200, megane wrote:
>> Is there any technical reason we couldn't call external functions
>> directly?
>
> In principle, this should be possible:
>
> 1) Just mark it "extern" in its own compilation unit
> 2) With the external inline file, also include a corresponding
>    header file (or generate external prototypes from the inline
>    declarations in CHICKEN itself)
>
> In practice, I think you'd run into the possibility that the fid
> might collide with an fid of a local procedure.
>
> So somehow the gensyms would need to be adjusted so that the fid
> is unique.

That would need something like function name mangling for the exported
toplevel functions. Like foo#bar becomes __foo_bar or something.
Exporting non-toplevel continuations wouldn't make much sense as they
change arbitrarily based on performed optimizations.

>
> Also, if you recompile the unit with the procedure, it might suddenly
> become non-customizable, or the fid changes.  Then, the call in the
> using unit would no longer be valid.

So a problem could be like this:

1. Module A exports foo and is compiled to A.o

2. Module B use foo from A and is compiled to B.o

3. Function foo is changed in A in a way that makes foo
   non-customizable. A.o is overwritten.

4. User tries to link program X with A.o and B.o, but gets weird link
   failures as B.o contains invalid calls to foo.

I guess to make this situation livable there would need to be a egg
recompilation system that would rebuild all affected eggs or something.
I.e. not really feasible.

Welp, that was an idea..

>
> In other words, we have no way to ensure a stable API, let alone ABI.
>
> Cheers,
> Peter