terdon has already addressed most of your points, but your question includes some issues that I think only I can address.

First, I’m not a moderator, and even though I have a lot of fake Internet points, I don’t have all that many special powers as a result.

Observation 3

I tend to assume that people interested in a question have read all the surrounding material (in the question, comments, answers, and linked questions), which is perhaps unfair. The impossibility of partial reads when the input block size is 1, as far as dd is concerned at least, is explained in this answer:

This suggests a solution: use an input block size of 1. No matter how the input is produced, there's no way for dd to read a partial block if the input block size is 1. (This is not completely obvious: dd could read a block of size 0 if it's interrupted by a signal — but if it's interrupted by a signal, the read system call returns -1. A read returning 0 is only possible if the file is opened in non-blocking mode, and in that case a read had better not be considered to have been performed at all. In blocking mode, read only returns 0 at the end of the file.)

Observation 4

When I wrote “POSIX read is very limited”, I was only saying that: read, as defined by POSIX, doesn’t have much in the way of options, and is pretty much limited to handling newline-delimited input as full lines. As a result of that, “in the context of your question, your read approach doesn’t work”. The two statements don’t qualify the same thing: the first qualifies POSIX read, the second qualifies your use of read. Because the question specifies POSIX only, you can’t use extensions to read as implemented in Bash for example.

In the context of the question, read is a built-in command of POSIX that can be successfully used to read an exact number of bytes as long as certain conditions are met.

As far as POSIX is concerned, read is a utility (traditionally a shell built-in, but the specification doesn’t require that), and as defined by POSIX it can’t be used to read an exact number of bytes.

Observation 6

I don’t know who upvoted muru’s answer, but it wasn’t me. If there’s one thing to always bear in mind regarding votes, it’s that you can never assume anything about them.

Here’s proof:

Neither of the arrows are highlighted, which means I haven’t voted either way.

terdon has already addressed most of your points, but your question includes some issues that I think only I can address.

First, I’m not a moderator, and even though I have a lot of fake Internet points, I don’t have all that many special powers as a result.

Second, it is quite possible that new users are subjected to more scrutiny than others, because their posts show up for review in the first posts review queue or in the late answers review queue; you can see my review from the latter here. I actually hadn’t realised until just now that the late answers queue only includes new users’ answers! My review wasn’t related to your being new; it was related to your answer being a late answer. I expect these to add relevant information which isn’t present in existing answers; I commented as such on your answer, since the ibs=1 approach had already been described elsewhere, but I didn’t take further action (e.g. suggesting that your answer should be deleted).

Observation 3

I tend to assume that people interested in a question have read all the surrounding material (in the question, comments, answers, and linked questions), which is perhaps unfair. The impossibility of partial reads when the input block size is 1, as far as dd is concerned at least, is explained in this answer:

This suggests a solution: use an input block size of 1. No matter how the input is produced, there's no way for dd to read a partial block if the input block size is 1. (This is not completely obvious: dd could read a block of size 0 if it's interrupted by a signal — but if it's interrupted by a signal, the read system call returns -1. A read returning 0 is only possible if the file is opened in non-blocking mode, and in that case a read had better not be considered to have been performed at all. In blocking mode, read only returns 0 at the end of the file.)

Observation 4

When I wrote “POSIX read is very limited”, I was only saying that: read, as defined by POSIX, doesn’t have much in the way of options, and is pretty much limited to handling newline-delimited input as full lines. As a result of that, “in the context of your question, your read approach doesn’t work”. The two statements don’t qualify the same thing: the first qualifies POSIX read, the second qualifies your use of read. Because the question specifies POSIX only, you can’t use extensions to read as implemented in Bash for example.

In the context of the question, read is a built-in command of POSIX that can be successfully used to read an exact number of bytes as long as certain conditions are met.

As far as POSIX is concerned, read is a utility (traditionally a shell built-in, but the specification doesn’t require that), and as defined by POSIX it can’t be used to read an exact number of bytes.

Observation 6

I don’t know who upvoted muru’s answer, but it wasn’t me. If there’s one thing to always bear in mind regarding votes, it’s that you can never assume anything about them.

Here’s proof:

Neither of the arrows are highlighted, which means I haven’t voted either way.