This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Make tests expect [ \t]+ pattern instead of \t for "info reg" command
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Ruslan Kabatsayev <b7 dot 10110111 at gmail dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 8 Jan 2018 11:33:44 +0400
- Subject: Re: [PATCH] Make tests expect [ \t]+ pattern instead of \t for "info reg" command
- Authentication-results: sourceware.org; auth=none
- References: <1515363510-18374-1-git-send-email-b7.10110111@gmail.com> <20180108042544.yzq3egkfph2c6v45@adacore.com> <CAHEcG96snuVzqnb5jpZXCDn6x=t_ek+9SnLK=5g-A1_qfOMgPA@mail.gmail.com>
> >> gdb/testsuite/ChangeLog:
> >>
> >> * gdb.arch/powerpc-d128-regs.exp: Replace expected "\[\t\]*" from
> >> "info reg" with "\[ \t\]*".
> >> * gdb.arch/altivec-regs.exp: Replace expected "\t" from "info reg" with
> >> "\[ \t\]+".
> >> * gdb.arch/s390-multiarch.exp: Ditto.
> >> * gdb.base/pc-fp.exp: Ditto.
> >> * gdb.reverse/i386-precsave.exp: Ditto.
> >> * gdb.reverse/i386-reverse.exp: Ditto.
> >> * gdb.reverse/i387-env-reverse.exp: Ditto.
> >> * gdb.reverse/i387-stack-reverse.exp: Ditto.
> >
> > No objection on my end. I might have used \\s instead of \[ \t\],
> > but perhaps there was a reason not to; and even if not, no point
> > in redoing it all now.
>
> \\s would also allow newlines, form feeds etc., which doesn't look
> like a good idea here.
Hmmm, true. Forgot about newlines in particular.
> >> - "pc +${valueof_pc}\t${valueof_pc} <.*>\[\r\n\]+fp +${valueof_fp}\t${valueof_fp}\[\r\n\]+"
> >> + "pc +${valueof_pc}\[ \t\]+${valueof_pc} <.*>\[\r\n\]+fp +${valueof_fp}\[ \t\]+${valueof_fp}\[\r\n\]+"
> >
> > This change looks like it's doing more than just allowing spaces
> > on top of tabs...
>
> Well it allows _multiple_ spaces/tabs instead of exactly one tab —
> exactly what we need to be compatible with space-alignment. In other
> respects I don't see what else it does.
My mistake. I was seeing 2 new lines, because one of the '+' lined up
exactly at the start of the next line when wraparound gets involved.
Upon re-examination, the change looks fine indeed.
--
Joel