[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Fix #1665 by blocking direct calls to externally inlineable
Re: [PATCH] Fix #1665 by blocking direct calls to externally inlineable procedures
Wed, 12 Feb 2020 19:46:59 +0200
mu4e 1.0; emacs 25.1.1
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
> 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.