Date: Tue, 12 Oct 2021 09:22:20 -0700
I've never touched the preprocessor, but I can't imagine it would be
challenging to duplicate the implementation of #error and tweak it to emit
a warning instead of an error. I see no particular reason why MSVC would
oppose #warning. I suspect the reason we don't support it now is that
#pragma message is superior since it accepts a string literal message
instead of a sequence of preprocessing tokens.
On Tue, Oct 12, 2021 at 6:20 AM Aaron Ballman via Liaison <
liaison_at_[hidden]> wrote:
> 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
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/10/0891.php
>
challenging to duplicate the implementation of #error and tweak it to emit
a warning instead of an error. I see no particular reason why MSVC would
oppose #warning. I suspect the reason we don't support it now is that
#pragma message is superior since it accepts a string literal message
instead of a sequence of preprocessing tokens.
On Tue, Oct 12, 2021 at 6:20 AM Aaron Ballman via Liaison <
liaison_at_[hidden]> wrote:
> 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
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/10/0891.php
>
Received on 2021-10-12 11:22:35