From: Marek Polacek <polacek@redhat.com>
To: David Malcolm <dmalcolm@redhat.com>
Cc: Joseph Myers <joseph@codesourcery.com>,
Jakub Jelinek <jakub@redhat.com>,
Martin Sebor <msebor@redhat.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH v3] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026]
Date: Tue, 16 Nov 2021 22:05:21 -0500 [thread overview]
Message-ID: <YZRxcWcQgVRRZz6p@redhat.com> (raw)
In-Reply-To: <e06ba686a6439dc04a5a48efd424c45f3335b8f8.camel@redhat.com>
On Tue, Nov 16, 2021 at 09:28:21PM -0500, David Malcolm wrote:
> On Tue, 2021-11-16 at 19:37 -0500, Marek Polacek wrote:
> > Sorry for a dumb question, but is this what you have in mind?
> >
> > /* LRE
> > PDF */
> > /* FSI
> > PDI */
> > and check that we warn for these?
>
> I mean something like the following multiline comments in which lines
> within them at the start, middle and end have unpaired constructs
> within a given line:
>
>
> /* RLI
> *
> */
>
> /*
> * RLI
> */
>
> /*
> *
> * RLI */
>
> and that we should warn for each case at the line containing the
> unpaired control character.
>
> (the above lines don't have the actual chars, just "RLI")
>
> Mostly this is just me trying to think about it from a black-box
> testing perspective, or in case we ever touch this code in the future
> (perhaps it's obviously correct by inspection of the implementation
> now, but let's have regression tests for these cases).
>
> Sorry to add more work, but here's an idea for another test case:
> multiple comments on one line:
>
> /* RLI */ /* PDF */
>
> where the closure of a comment should trigger closing a "context", so
> we should complain about the above.
No problem, I've added these.
> >
> > > > > > @@ -1505,13 +1855,17 @@ lex_identifier (cpp_reader *pfile,
> > > > > > const uchar *base, bool starts_ucn,
> > > > > > {
> > > > > > /* Slower version for identifiers containing UCNs
> > > > > > or extended chars (including $). */
> > > > > > - do {
> > > > > > - while (ISIDNUM (*pfile->buffer->cur))
> > > > > > - {
> > > > > > - NORMALIZE_STATE_UPDATE_IDNUM (nst, *pfile->buffer-
> > > > > > >cur);
> > > > > > - pfile->buffer->cur++;
> > > > > > - }
> > > > > > - } while (forms_identifier_p (pfile, false, nst));
> > > > > > + do
> > > > > > + {
> > > > > > + while (ISIDNUM (*pfile->buffer->cur))
> > > > > > + {
> > > > > > + NORMALIZE_STATE_UPDATE_IDNUM (nst, *pfile-
> > > > > > >buffer->cur);
> > > > > > + pfile->buffer->cur++;
> > > > > > + }
> > > > > > + }
> > > > > > + while (forms_identifier_p (pfile, false, nst));
> > > > >
> > > > > Is the above purely a whitespace change?
> > > >
> > > > Yes.
> > >
> > > If I'm reading things correctly, these lines in the existing code
> > > were
> > > correctly indented, so is there a purpose to this change? If not,
> > > please can you remove this change from the patch (to minimize the
> > > change to the history).
> >
> > I dropped that change then. Sometimes it's hard to resist fixing
> > formatting. ;)
>
> Thanks. But I don't think the existing formatting in the code *was*
> broken; I thought the patch was taking correct formatting and breaking
> it (hence my objection to a whitespace change). If I misread this,
> sorry.
I think it was, we're supposed to format do-while as
do
{
}
while (...);
but it's obviously not a big deal.
> Hopefully the above makes sense and is constructive; let me know when
> you push your patch so that I can work on my followup.
Pushed now. Thanks!
Marek
next prev parent reply other threads:[~2021-11-17 3:05 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 16:36 [PATCH] libcpp: Implement -Wbidirectional " Marek Polacek
2021-11-01 22:10 ` Joseph Myers
2021-11-02 17:18 ` [PATCH v2] " Marek Polacek
2021-11-02 19:20 ` Martin Sebor
2021-11-02 19:52 ` Marek Polacek
2021-11-08 21:33 ` Marek Polacek
2021-11-15 17:28 ` [PATCH] libcpp: Implement -Wbidi-chars " Marek Polacek
2021-11-15 23:15 ` David Malcolm
2021-11-16 19:50 ` [PATCH v2] " Marek Polacek
2021-11-16 23:00 ` David Malcolm
2021-11-17 0:37 ` [PATCH v3] " Marek Polacek
2021-11-17 2:28 ` David Malcolm
2021-11-17 3:05 ` Marek Polacek [this message]
2021-11-17 22:45 ` [committed] libcpp: escape non-ASCII source bytes in -Wbidi-chars= [PR103026] David Malcolm
2021-11-17 22:45 ` [PATCH 2/2] libcpp: capture and underline ranges " David Malcolm
2021-11-17 23:01 ` Marek Polacek
2021-11-30 8:38 ` [PATCH] libcpp: Implement -Wbidi-chars for CVE-2021-42574 [PR103026] Stephan Bergmann
2021-11-30 13:26 ` Marek Polacek
2021-11-30 15:00 ` Stephan Bergmann
2021-11-30 15:27 ` Marek Polacek
2022-01-14 9:23 ` Stephan Bergmann
2022-01-14 13:28 ` Marek Polacek
2022-01-14 14:52 ` Stephan Bergmann
2021-11-02 20:57 ` [PATCH 0/2] Re: [PATCH] libcpp: Implement -Wbidirectional " David Malcolm
2021-11-02 20:58 ` [PATCH 1/2] Flag CPP_W_BIDIRECTIONAL so that source lines are escaped David Malcolm
2021-11-02 21:07 ` David Malcolm
2021-11-02 20:58 ` [PATCH 2/2] Capture locations of bidi chars and underline ranges David Malcolm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YZRxcWcQgVRRZz6p@redhat.com \
--to=polacek@redhat.com \
--cc=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=joseph@codesourcery.com \
--cc=msebor@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).