Process substitution issue in GDB's shell - bash

Question

The following code, readTwice.c, reads twice from standard input:
int main()
{
char s[8]={0};
read(0, (void *)s, (size_t) 3);
read(0, (void *)(s + 4), (size_t) 3);
for (int i = 0; i < 8; i++)
printf("%d: 0x%x\n", i, s[i]);
return 0;
}
My objective is to, while debugging the corresponding binary, feed the first read() with a first file a (say, created by echo a > a), and the second read() with a second file b (say, created by echo b > b).
Outside GDB, the following bash 5.0 command has the desired effect:
$ ./readTwice < <(cat a;cat b)
0: 0x61
1: 0xa
2: 0x0
3: 0x0
4: 0x62
5: 0xa
6: 0x0
7: 0x0
However, when running the binary in GDB 8.2.1 with the same process redirection, the first read() call also reads the beginning of the second file:
$ gdb -q readTwice
Reading symbols from readTwice...(no debugging symbols found)...done.
(gdb) run < <(cat a;cat b)
Starting program: /home/av/root-me/ch77/readTwice < <(cat a;cat b)
0: 0x61
1: 0xa
2: 0x62
3: 0x0
4: 0xa
5: 0x0
6: 0x0
7: 0x0
[Inferior 1 (process 4710) exited normally]
(gdb)
Could you help me understand this behaviour and/or tell me about a command having the desired effect ?

Answer 1

The input to your program consists of 4 characters:
'a' '\n' 'b' '\n'
Inside your program you use two reads:
read(0, (void *)s, (size_t) 3);
read(0, (void *)(s + 4), (size_t) 3);
read doesn't read exactly 3 characters. It reads up to 3 characters and returns the number of characters read, see man read(2). I assume by default STDIN_FILENO is blocking on your platform, so it should read at least 1 character.
Possible outcomes:
Both reads read 1 byte. s will have {'a',0,0,0,'\n',0,0,0}. There are 2 unread bytes in the input.
First read read 1 byte, second reads 3 bytes. s will have {'a',0,0,0,'\n','b','\n',0}
First read reads 3 bytes, second reads 1 byte. s will have {'a','\n','b',0,'\n',0,0,0}. This is the output you observe in gdb.
First read reads 2 bytes, second reads 2 bytes. s will have {'a','\n',0,0,'b','\n',0,0}. This is the output you observe when running in shell.
Hopefully you get the idea by now.
Most probably your operating system implements read on STDIN_FILENO in a line buffered fashion on your platform, so the two most possible outcomes are the ones you are observing.