On Tue, Oct 12, 2021 at 9:11 AM Niall Douglas via Ext
<ext_at_[hidden]> wrote:
>
> On 12/10/2021 13:53, Aaron Ballman via Ext wrote:
> > On Tue, Oct 12, 2021 at 8:48 AM Andrew Tomazos via Ext
> > <ext_at_[hidden]> wrote:
> >>
> >> Oops. I missed that bit: MSVC doesn't support #warning ?
> >
> > Correct. They support something similar but under a different spelling:
> >
> > #pragma message("oh no")
> >
> > https://docs.microsoft.com/en-us/cpp/preprocessor/message?view=msvc-160
> >
> >> Why not? Did MSVC consider supporting #warning and then decided against
> it? What's the story there?
> >
> > Uncertain, but hopefully a Microsoft representative can say more if
> > there's a problem with supporting this (and if there is, whether it's
> > a problem for their C implementation as well).
>
> I assume that the sequence of code points after #warning is to be
> handled identically to how #error handles its sequence of codepoints?

The sequence of preprocessing tokens following #warning are expected
to be handled the same as the sequence of preprocessing tokens
following #error.

> I ask because #error is a touch broken with certain characters, which is
> very annoying:
>
> https://godbolt.org/z/MPWcYrhnv
>
> I don't care if a special case is just made for ' when used inside
> #error or #warning, but this has been a consistent gotcha since I first
> started writing in C 25 years ago and I'd like it to go away please.

Understandable that it's a gotcha, but it helps to remember that what
follows those directives is required to be valid preprocessing tokens.
(Personally, I tend to use a string literal to avoid exactly those
sorts of problems you point out in your link.)

~Aaron

>
> Niall
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2021/10/18017.php