From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) by sourceware.org (Postfix) with ESMTPS id D77013858CDA; Wed, 11 Jan 2023 09:33:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D77013858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-15bb8ec196aso3178407fac.3; Wed, 11 Jan 2023 01:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wBp1K/pgcBeGD103xFjzJWteURdp22sKr9F5Fxvdz2Q=; b=Xc1rZw+5xf1Hh8MmJfM2h49uYKO5YebkqkaEQh6NUuEEKC1FVDGmL2g8LdDTxRMgmv PDCm5B7fo3aGcWMB++sK0A7broI08JrWahTnSvV2ZhAGUnZ1DDm1zwF9kQV2NAixccH8 l1OEo0PkCIrcAxuCPmgjCgXreXvThL/5cfqdZUxxDgAxT1lunVPsGDPg6gcuavFrH4Cv J8QDlayWjYfqaEenCZTK8iORyPZMleCRHRdvjPVC3kEDNlBBFJtvBZLNkY7ipUshBY+N +pxHapZuFVeApk1FXmxC3/kpBBdTOdtGkexRkUlSHuu2BbFkvYiIQVKyBHVX6cCKWvDE xl0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wBp1K/pgcBeGD103xFjzJWteURdp22sKr9F5Fxvdz2Q=; b=RVB6PFGKrhnHuvvV9ZGcXARnigMJNJ9RXb/SUo3nnPzK2i/eQkOvT97coXY3bxGT1F v5v2VJx7k1oM5pCKs3y0sjN9DjBL4muoar2cbVaOrRX+ZSWF0V3wUDOHVrAHKKwcxvK4 nGVNIPA/FiJxsXAt3KkedH4xavTMkuc97gh4Vg1XT/vdEgK6V3Y4qU0uEjFCRY0t8l0/ GDOsetsKpZMQmDlAzQrnQnV8+0vz6hD6vRnesjUBeXaG3Aivv41eHez1IfUokEt8hBiz IkZIYT31PX34GnvLmLmDEU2mNTyagH4Ee2lPb6KjIlJifEYzeVnOv8U9nEL+brjRkKET LYhA== X-Gm-Message-State: AFqh2krZSD1kj8eWvBmLZCcIULEE7SHLegkAr9KNX9vLaaSh5lQu/Ye8 BEIu7xnqdEb3itgkQ6d84v+0lZevgyqIWwj/jKw= X-Google-Smtp-Source: AMrXdXvJawgXdZsRiqaRN69ilun7Ecct78o9i2FYlvWkf36sBOWgn4lHNfp1Yk78OGFjqgpwO0QU3p2pFB7An13fQyo= X-Received: by 2002:a05:6870:578f:b0:14f:ac78:ac7f with SMTP id i15-20020a056870578f00b0014fac78ac7fmr3933873oap.112.1673429627101; Wed, 11 Jan 2023 01:33:47 -0800 (PST) MIME-Version: 1.0 References: <639FE88D.7090408@gmail.com> <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> <63A3DF0E.1050902@gmail.com> <63A67964.6080902@gmail.com> <63B7967B.60502@gmail.com> <63BE1F2F.8030609@gmail.com> In-Reply-To: <63BE1F2F.8030609@gmail.com> From: NightStrike Date: Wed, 11 Jan 2023 04:33:32 -0500 Message-ID: Subject: Re: testsuite under wine To: jcb62281@gmail.com Cc: Jacek Caban , fortran@gcc.gnu.org, Eric Pouech , "gcc@gcc.gnu.org" , dejagnu@gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer 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.