llvm dev - Jul 2019 - Why do we avoid pure virtual functions in compiler-rt?

Hi all,

I am just working on some code and noticed that we refrain from declaring any
pure virtual functions in compiler-rt.
Our conceptually abstract classes are therefore not considered “abstract” in the
C++ sense.
This turns some compile-time errors into run-time errors. Is there a reason we
do this?

Example code:

class SymbolizerProcess {
  [...]
  virtual bool ReachedEndOfOutput(const char *buffer, uptr length) const {
    UNIMPLEMENTED();
  }
  [...]
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190724/470da1ca/attachment.html>

If I had to make a wild guess, it's to avoid vtables referring
to __cxa_pure_virtual. I don't know why that would be problematic, but ASan
already takes great care to avoid calling back into libc while its running.

On Wed, Jul 24, 2019 at 3:33 PM Julian Lettner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> I am just working on some code and noticed that we refrain from declaring
> any pure virtual functions in compiler-rt.
> Our conceptually abstract classes are therefore not considered “abstract”
> in the C++ sense.
> This turns some compile-time errors into run-time errors. Is there a
> reason we do this?
>
> Example code:
>
> class SymbolizerProcess {
>   [...]
>   virtual bool ReachedEndOfOutput(const char *buffer, uptr length) const {
>     UNIMPLEMENTED();
>   }
>   [...]
> }
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190726/26ec85a3/attachment.html>