From: Jacob Bachmeyer <jcb62281@gmail.com>
To: NightStrike <nightstrike@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: Fri, 23 Dec 2022 22:00:36 -0600 [thread overview]
Message-ID: <63A67964.6080902@gmail.com> (raw)
In-Reply-To: <CAF1jjLtyiZtm_CUT7x_qMbPYyGoSF=DGSLjKe1CaUWMvabsFOQ@mail.gmail.com>
NightStrike wrote:
> On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer <jcb62281@gmail.com> 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
next prev parent reply other threads:[~2022-12-24 4:00 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 [this message]
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
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=63A67964.6080902@gmail.com \
--to=jcb62281@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=nightstrike@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).