On Sat, Mar 2, 2024 at 8:59 PM Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Saturday, 2 March 2024 16:36:41 PST Frederick Virchanza Gotham via Std-
> Proposals wrote:
> > An exception is thrown from somewhere, and I can
> > at least see the type's name:
> >
> > char const *const plugin_name = "FieryShadow"; // plugin name
> > not known until runtime
> >
> > catch(...)
> > {
> > type_info const &ti = typeid_except();
> > if ( strstr( ti.name(), plugin_name ) ) throw
> > std::runtime_error("exception thrown from active plugin");
> > }
>
> First, the request is that you add the motivation to the paper, not reply by
> email.
>
> Second, this example will NEVER match, no matter what you name your class,
> because typeinfo::name() returns an ABI-specific string.

To be *completely* fair to the OP, it doesn't have to match exactly.
`strstr` searches for a substring within a string. All that has to
match is that the exception name mangled by the ABI contains the
sequence of characters "FieryShadow" somewhere within it. And most ABI
name mangling schemes pass through the literal ASCII text of a name as
is. So if the plugin puts "FieryShadow" inside the extension class
name, this will detect it.

Now even if the ABI does so, that still doesn't make this code
actually work, as there's no rule that a plugin must use its own exact
name in its exception class names (either directly or in its
namespace). And even if they do, it's still very possible for them to
emit other exceptions (either accidentally or on purpose).

So even if everything aligns for this to "work", it doesn't really do
what the code seems to want to do: identify the source of an
exception. It's more of a guess whose accuracy is highly dubious and
based entirely on factors out of the program's control.

That doesn't make it pointless, but it is decidedly low on point.

> That means you need an
> ABI-specific encoding of the string to compare to on compilation or an ABI-
> specific decoding on use, at runtime. If you're going to do this with ABI-
> specific code, then you need to explain in your paper that there's no already-
> available ABI-specific way to do what you want to do, or that the ABI-specific
> additions required are minor and acceptable. Either way, you'll need to deal
> with that in the example, but the need to have non-standard code in the
> example about adding a feature to the example will lessen your proposal's
> value. Also note your example talks about DSOs, which are not in the Standard
> either.
>
> Third, comparing classes by name is poor programming practice. What happens if
> the exception class in question was in an unnamed namespace? How do you
> distinguish then two classes of the same name from each other? And because you
> said DSO, you *can* have non-unnamed-namespace classes of the same name.
>
> Try to think of more standards-compliant and less fragile examples.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals