> EFAULT is kinda interesting in that POSIX documents its existence but does > not require it to ever be returned. Here's what POSIX says normatively: > [EFAULT] > Bad address. The system detected an invalid address in attempting to > use an argument of a call. The reliable detection of this error > cannot be guaranteed, and when not detected may result in the > generation of a signal, indicating an address volation, which is > sent to the process. > > _Informatively_ (no compliance requirement!) it says this in the > rationale: > POSIX.1 requires (in the ERRORS sections of function descriptions) > certain error values to be set in certain conditions because many > existing applications depend on them. Some error numbers, such > as [EFAULT], are entirely implementation-defined and are noted > as such in their description in the ERRORS section. This section > otherwise allows wide latitude to the implementation in handling > error reporting. > ... > [EFAULT] Most historical implementations do not catch an error > and set errno when an invalid address is given to the > functions wait(), time(), or times(). Some implementations > cannot reliably detect an invalid address. And most > systems that detect invalid addresses will do so only > for a system call, not for a library routine.
POSIX is a wimpy subset of UNIX, specified so unstrictly that it becomes difficult to build secure software upon the foundation. I believe if you don't teach people the need for strict careful specifications -- by example -- then don't be surprised they don't learn the lessons elsewhere, and their results are chaotic and fragile. the lack of a strict decision is a decision to be sloppy. sand. too much is built on sand.
