public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: NightStrike <nightstrike@gmail.com>
To: jcb62281@gmail.com
Cc: Jacek Caban <jacek@codeweavers.com>,
	fortran@gcc.gnu.org,  Eric Pouech <eric.pouech@orange.fr>,
	"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	dejagnu@gnu.org
Subject: Re: testsuite under wine
Date: Wed, 11 Jan 2023 04:33:32 -0500	[thread overview]
Message-ID: <CAF1jjLvbc1DGjM2T4nhLbDrifroVc7ACVKC+=uctvQ4acV=qeA@mail.gmail.com> (raw)
In-Reply-To: <63BE1F2F.8030609@gmail.com>

On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer <jcb62281@gmail.com> wrote:
>
> NightStrike wrote:
> > [...]
> > I did another little test to try to better understand your point.  I
> > ran a linux native testsuite under a simulator that just sets SIM to "
> > ".  This resulted in extra ^M's also, although many tests pass because
> > they're already looking for \r\n to accommodate windows.  So I think
> > I've come around to grasp what you've been heroically re-explaining...
> >
> > So if we have to modify every test in the entire testsuite to check
> > for zero or more \r's followed by zero or more \n's, would it be
> > better to add a dg-output-line proc that does this automatically
> > everywhere?
>
> Two problems:  first, you need zero-or-more \r and *one*-or-more \n.
> Second, dg-output is not defined as an anchored match, and therefore
> cannot do this automatically.

"or more" \n is valid?  That would make the rust bug of \r\r\n\n pass
when I assume it shouldn't.

> >   I feel like changing every output pattern test won't be
> > too maintainable.  You had mentioned previously modifying ${tool}_load
> > to filter out extra \r's, but I couldn't see where or how to do that.
> >
> > For completeness, setting a random selection of tests to look for
> > \r*\n? worked (this would cover even deprecated systems that only use
> > CR as well as flagging the weird rust case of \r\r\n\n as bad).
>
> Do not worry about classic Mac OS---running DejaGnu on that platform is
> not possible, nor is it possible to run test programs remotely on that
> platform.  Classic Mac OS is a pure-GUI system with no command interface
> whatsoever.  Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl
> exec(n) command.  Due to limitations of the platform, porting Expect to
> classic Mac OS is simply not possible.  Any compatibility layer would be
> reasonably expected to translate CR<->LF, if, for example, someone wrote
> a telnet server (and associated POSIX-alike environment) for Mac OS.
>
> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU
> system that uses POSIX line endings.  DejaGnu should run normally there.
>
> Are there other systems that used bare CR as end-of-line?  If not, the
> correct pattern is therefore {\r*\n} (here written using braces as
> quotes around the pattern).

Maybe none that matter.  From
https://en.wikipedia.org/wiki/Newline#Representation:

Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80,
Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9

The article also goes on to mention that OpenVMS and RSX-11 can be
configured to use CR.

  reply	other threads:[~2023-01-11  9:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAF1jjLtJW0juQR6L-VybJ8SSaqkfi=qN9FnxJVaY=oQBtkSLxA@mail.gmail.com>
     [not found] ` <3f62bac2-ac1b-5c55-2488-ede2389d35d2@netcologne.de>
     [not found]   ` <CAF1jjLvJU2fnU0u0p9SwPre5mnhFdmv9pm_OvZGOvjQApCROqw@mail.gmail.com>
2022-12-17 10:52     ` Thomas Koenig
2022-12-17 23:24       ` NightStrike
2022-12-18  3:44         ` Jacob Bachmeyer
2022-12-18 21:13           ` NightStrike
2022-12-19  4:29             ` Jacob Bachmeyer
2022-12-19 10:43               ` Torbjorn SVENSSON
2022-12-19 11:00                 ` NightStrike
2022-12-19 11:13               ` NightStrike
2022-12-20  3:51                 ` Jacob Bachmeyer
     [not found]               ` <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com>
2022-12-22  1:01                 ` NightStrike
2022-12-22  4:37                   ` Jacob Bachmeyer
2022-12-23 10:36                     ` NightStrike
2022-12-23 12:43                       ` Eric Pouech
2022-12-24  4:00                       ` Jacob Bachmeyer
2022-12-24 11:05                         ` Mark Wielaard
2023-01-05  2:50                         ` NightStrike
2023-01-06  3:33                           ` Jacob Bachmeyer
2023-01-06  3:44                             ` Jerry D
2023-01-08  7:12                             ` NightStrike
2023-01-11  2:30                               ` Jacob Bachmeyer
2023-01-11  9:33                                 ` NightStrike [this message]
2023-01-12  4:11                                   ` Jacob Bachmeyer
2023-01-06  3:41                           ` Jerry D

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='CAF1jjLvbc1DGjM2T4nhLbDrifroVc7ACVKC+=uctvQ4acV=qeA@mail.gmail.com' \
    --to=nightstrike@gmail.com \
    --cc=dejagnu@gnu.org \
    --cc=eric.pouech@orange.fr \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=jacek@codeweavers.com \
    --cc=jcb62281@gmail.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).