Uh, since when is it acceptable for memmove to simply copy in the opposite direction? My understanding is that it must work no matter which part of the data is overlapping, as if it made a temporary copy somewhere else entirely. Simply reversing the copy direction cannot guarantee this… memmove(&s[1], &s[3], 3);
I think he oversimplified a bit there. You at any rate sometimes need to copy downwards, and sometimes need to copy upwards, so having the direction flag smashed by signals kills you either way, but I agree that his comment as-phrased seems very weird.
Author here. The claim is that memset() (and memcpy(), memmove() and similar functions) were not listed as “async-signal safe” by POSIX, which means you can’t call them from a signal handler. A working theory (one of the links in the blog post) is that it was excluded from POSIX because of the direction flag on x86 hardware. But from the discussion on Hacker News, it appears that is no longer the case, but is a recent change (2016) to the POSIX standard.
When POSIX was developed in the late 80s and early 90s none of the UNIX vendors cared anything about x86 hardware. Sun had Solaris/Sparc, IBM had AIX/Power, DEC had Alpha/Tru64, HP had HP-UX/PA-RISC, etc.
The only UNIX that ran on x86 (that I know of) was Microsoft Xenix, but they never implemented POSIX, and likely didn’t care too much, for obvious reasons.
Most likely explanation, considering it’s in the list in newer versions is that it was just an oversight.
Uh, since when is it acceptable for memmove to simply copy in the opposite direction? My understanding is that it must work no matter which part of the data is overlapping, as if it made a temporary copy somewhere else entirely. Simply reversing the copy direction cannot guarantee this… memmove(&s[1], &s[3], 3);
I think he oversimplified a bit there. You at any rate sometimes need to copy downwards, and sometimes need to copy upwards, so having the direction flag smashed by signals kills you either way, but I agree that his comment as-phrased seems very weird.
simplified is
That would be memcpy (although it also makes no guarantee on the order/direction)
What’s your point? memmove() is just an overlap-safe memcpy(), trivially implemented with variable direction and atomic width.
Wouldn’t copying in reverse work just fine for that? Copy 3 to 5, then 2 to 4, and finally 1 to 3?
EDIT: Whoops, mixed up the source and dest.
Is the claim that signal handling does not save and restore the direction flag?
Author here. The claim is that memset() (and memcpy(), memmove() and similar functions) were not listed as “async-signal safe” by POSIX, which means you can’t call them from a signal handler. A working theory (one of the links in the blog post) is that it was excluded from POSIX because of the direction flag on x86 hardware. But from the discussion on Hacker News, it appears that is no longer the case, but is a recent change (2016) to the POSIX standard.
EDIT: clarify a point.
I don’t believe it.
When POSIX was developed in the late 80s and early 90s none of the UNIX vendors cared anything about x86 hardware. Sun had Solaris/Sparc, IBM had AIX/Power, DEC had Alpha/Tru64, HP had HP-UX/PA-RISC, etc.
The only UNIX that ran on x86 (that I know of) was Microsoft Xenix, but they never implemented POSIX, and likely didn’t care too much, for obvious reasons.
Most likely explanation, considering it’s in the list in newer versions is that it was just an oversight.
ok, thanks