interaction of _read on fd 0 in terminal

[spk121]

Windows Terminal version

1.19.2682.0

Windows build number

Version 10.0.22621.2428

Other Software

No response

Steps to reproduce

Compile the attached, run, and press enter multiple times. Behavior is the same with MSVC in Visual studio 2022 and with latest MinGW with GCC using 64-bit UCRT.

#include <io.h>
#include <stdio.h>
#include <errno.h>


int main()
{
  int fd = 0;
  printf("fd = %d\n", fd);

  int ret;
  char buf[128];

  while (1)
    {
      errno = 0;
      ret = _read (fd, buf, 1);
      printf("ret = %d, errno = %d, char = %u\n", ret, errno, buf[0]);
    }
  return 0;
}

Expected Behavior

I expected the behavior found on MinGW's mintty, when I press the enter key multiple times.

fd = 0

ret = 1, errno = 0, char = 10

ret = 1, errno = 0, char = 10

ret = 1, errno = 0, char = 10

ret = 1, errno = 0, char = 10

Actual Behavior

This is what happens in Terminal when I press the enter key multiple times on a recent Terminal

fd = 0


ret = 1, errno = 0, char = 13
ret = -1, errno = 13, char = 13


ret = 1, errno = 0, char = 13
ret = -1, errno = 13, char = 13


ret = 1, errno = 0, char = 13
ret = -1, errno = 13, char = 13


ret = 1, errno = 0, char = 13
ret = -1, errno = 13, char = 13

[spk121]

Apparently something having to do with handling of CR LF line endings in terminal, but, that _read errors with EACCES is unexpected.

[zadjii-msft]

I'm gonna reckon that this maybe regressed due to #15783. I'll tag @lhecker to investigate. Thanks for the minimal repro!

[zadjii-msft]

maybe #15662?

[spk121]

I noticed that if you change the _read call to _read(fd, buf, 2) it works fine and always returns 1 character of ASCII 10.. It is like the _read needs a two character buffer to hold (i presume) "\r\n" before some sort of cooked logic turns it into "\n" before storing it into buf.

[lhecker]

I believe this is a duplicate of #16223. I haven't checked how _read() is implemented but I bet it's a wrapper around ReadFile()...