From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) by sourceware.org (Postfix) with ESMTPS id 981743858D1E; Sat, 24 Dec 2022 04:00:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 981743858D1E 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-oo1-xc32.google.com with SMTP id t15-20020a4a96cf000000b0049f7e18db0dso1046769ooi.10; Fri, 23 Dec 2022 20:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:references:subject:cc:to :mime-version:user-agent:reply-to:from:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=LPltprXa3g2ufAWSjWmX4bFYWdNsrYWEbM49Sjbz7j8=; b=GZ4c0PDws09sCTsG4cth10aLe3J7IpKa6w8OaPxsTPOXFOkSSKkNbgj44Xk2/+5YtN ST1uYs7CNt0Ve+FstzR1dMTjcgclwkjCJ488Rvlzs07zYw8pIG+EUXBA0rDQ1MW9OZnT S+fGhIpKkwX00GWR5Zjbo23e4RKa4VoiHA0vB3X+PhL6IbuIm6SZ/tJ7NNJ+3UeC3aCa NUo1gS8OuX36yola01yjKzG5leJYmnZrL5k2g6fWJWVlhfa8COIn2eUn4BdCaOtYi9mv /PS5HWjhZL0QcG/IKjFysHG+/Cu7IPTvxoxFpTDA4We5L+LAHCbtvbfvKutIL+ZhDaRW 3sBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:references:subject:cc:to :mime-version:user-agent:reply-to:from:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LPltprXa3g2ufAWSjWmX4bFYWdNsrYWEbM49Sjbz7j8=; b=XmPdu4BVBLtrKAQ54iH8wkVHhRKdGErDqkQz9vs9WAAqKumHOLyOOF8vTrHeu1va8L fgsjwf4GkLSciYekp/3acRgtfa4uz1hxlT+F9lHXvibzlg0tV6s4iHjx7LHCDx4/gdkE iDF19Cy7perUBo7xcJ/wHMIzEIDT4m8eied5ozZKHmq1E/3bTA7ZmkmruhVpZDgvMbCd 1WslRtilJ+1uy/BaPIB1ua3pVNuxWYRmqZoucqyhValzkNLDy7nKXL6C769t2luCzCXk 7PR1ye+IqF1xqG9eIqZvimUU/cRE+zjC5XOAU+FelVhWq6cjbPyH5KuHOqAhUl2rOg8u MH7Q== X-Gm-Message-State: AFqh2kp7GonfmF5sBdCJanBpQJAjZ9Eza4Oqd8s+rJ4IAfwiDFZwJgQM p7MoQl0wqyrv6oMXXFK3A7Q= X-Google-Smtp-Source: AMrXdXvlpNLusLX6WK04ynU9PZK+cJG4Q0DmqwvIC7DSZD+PDHAIUtwx766IJ1iul0MCCT7nLGAX/g== X-Received: by 2002:a4a:ca93:0:b0:49f:8720:d5b2 with SMTP id x19-20020a4aca93000000b0049f8720d5b2mr3105014ooq.8.1671854437833; Fri, 23 Dec 2022 20:00:37 -0800 (PST) Received: from [127.0.0.1] ([70.133.144.146]) by smtp.gmail.com with ESMTPSA id d18-20020a4ad352000000b0049fd6bfde95sm2047500oos.26.2022.12.23.20.00.36 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 23 Dec 2022 20:00:37 -0800 (PST) Message-ID: <63A67964.6080902@gmail.com> Date: Fri, 23 Dec 2022 22:00:36 -0600 From: Jacob Bachmeyer Reply-To: jcb62281@gmail.com User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 SeaMonkey/1.1.17 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: NightStrike CC: Jacek Caban , fortran@gcc.gnu.org, Eric Pouech , "gcc@gcc.gnu.org" , dejagnu@gnu.org Subject: Re: testsuite under wine References: <639FE88D.7090408@gmail.com> <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> <63A3DF0E.1050902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,FREEMAIL_REPLYTO_END_DIGIT,NICE_REPLY_A,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: NightStrike wrote: > On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote: > >> NightStrike wrote: >> >>> [...] >>> Second, the problems with extra \r's still remain, but I think we've >>> generally come to think that that part isn't Wine and is instead >>> either the testsuite or deja. So I'll keep those replies to Jacob's >>> previous message. >>> >>> >> Most likely, it is a combination of the MinGW libc (which emits "\r\n" >> for end-of-line in accordance with Windows convention) and the kernel >> terminal driver (which passes "\r" and translates "\n" to "\r\n" in >> accordance with POSIX convention). Wine, short of trying to translate >> "\r\n" back to "\n" in accordance with POSIX conventions (and likely >> making an even bigger mess---does Wine know if a handle is supposed to >> be text or binary?) cannot really fix this, so the testsuite needs to >> handle non-POSIX-standard line endings. (The Rust tests probably have >> an outright bug if the newlines are being duplicated.) >> > > You may be onto something here. I ran wine under script as `script -c > "wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r > prepended to the \r\n. I was making the mistake previously of running > wine manually and capturing it to a file as `wine64 ./a.exe > out`, > which as several have pointed out in this thread, that would disable > the quirk, so of course it didn't reveal any problems. I'm behind, > but I'll catch up to you guys eventually :) > So close, and yet so far... script(1) /also/ uses a pty, so it is getting the same translations as Expect and therefore DejaGnu. > So at least we know for sure that this particular instance of extra > characters is coming from Wine. Maybe Wine can be smart enough to > only translate \n into \r\n instead of translating \r\n into \r\r\n. > Jacek / Eric, comments here? I'm happy to try another patch, the > first one was great. > I doubt that Wine is doing that translation. MinGW libc produces output conformant to Windows conventions, so printf("\n") on a text handle emits "\r\n", which Wine passes along. POSIX convention is that "\n" is translated to "\r\n" in the kernel terminal driver upon output, so the kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding "\r\r\n" at the pty master end. This is why DejaGnu testsuites must be prepared to discard excess carriage returns. The first CR came from MinGW libc; the second CR came from the kernel terminal driver; the LF was ultimately passed through. > Rust is getting \r\r\n\n (as opposed to \r\n\r\n), so... yeah. Could > be the rust test, could be the rust frontend, could be another weird > Wine interaction. > That is probably either a Rust bug or the intended behavior. Does the test produce "\n\n" or "\r\n\n" when run natively? (Note that the terminal driver could reasonably optimize: once one CR has been produced, any number of LF may follow: the cursor is assumed to remain at the left edge. It is possible that the kernel terminal driver could even strip the second CR in "\r\n\r\n" since its only effect on an actual serial terminal would be wasting transmission time.) -- Jacob