On Friday, 25 September 2026 08:09:59 Pacific Daylight Time Frederick Virchanza
Gotham via Std-Proposals wrote:
> Okay so now that we have this cool new compiler, let's play around
> with it. Let's write an efficient function to copy a string:
>
> void StrCopy(char *p, char const *q)
> {
> while ( *p++ = *q++ );
> }
>
> Let's document this function to say that you shouldn't pass nullptr's
> to this function, and that the behaviour is undefined if you do give
> it nullptr's.

Ok, so passing nullptr to it is UB. The compiler's actual behaviour is
irrelevant.

Ignoring the entire section about what would happen if the behaviour was
something or other, because it is irrelevant

> What if a
> 'nullptr_error' exception could escape a function marked 'noexcept',
> but every other exception type would result in the calling of
> 'std::terminate'? Perhaps this would be achieved by introducing a new
>
> exception base class called "std::escapee", and so then we'd have:
> class nullptr_error : public std::exception, public std::escapee {};
>
> And so if you have a function marked as 'noexcept', and if an
> exception tries to escape, check if the exception is derived from
> 'std::escapee', and if it is, let it escape -- otherwise call
> std::terminate. Is this too crazy?

Since it's compiler-specific behaviour, you can do whatever you want. It's not
portable and no one should expect it to work elsewhere. And it's out of scope
for the std mailing list.

> I'm just throwing out ideas here to get discussion going.

There isn't one. This is neither a proposal nor about standard. If you meant
to propose something, you forgot the actual proposal. If you meant to discuss
something, you've posted to the wrong list and you didn't make it about the
standard.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.