On Sun, 3 Dec 2017, Theo de Raadt wrote:
> > 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:
...
> POSIX is a wimpy subset of UNIX, specified so unstrictly that it
> becomes difficult to
> 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
Standards state a contract or implication: *if* you, the developer follow
_these_ rules, *then* the standardized item will follow _these_other_
rules (if compliant). If you violate the implication, then the standard
no longer applies and you have lost the guarantees of the standard.
_If_ you
On Sat, Dec 02, 2017 at 11:54:23AM -0700, Theo de Raadt wrote:
> > > Wouldn't be the first error in POSIX. The documents have gotten
> > > sloppier. I think this is due to their commitee not acquiring any
> > > sensible young blood.
> >
> > fwiw, the "return zero and only zero" behavior traces
> > Wouldn't be the first error in POSIX. The documents have gotten
> > sloppier. I think this is due to their commitee not acquiring any
> > sensible young blood.
>
> fwiw, the "return zero and only zero" behavior traces back at least
> as far as here (SUSv2, I think):
>
>
On Sat, Dec 02, 2017 at 11:05:17AM -0700, Theo de Raadt wrote:
> > TL;DR: POSIX.1-2008 says gettimeofday(2) can't return anything but 0,
> > but we return -1 on invalid input.
>
> It must return -1 to indicate the tp pointer is to invalid memory.
> All system calls indicate invalid pointer
> TL;DR: POSIX.1-2008 says gettimeofday(2) can't return anything but 0,
> but we return -1 on invalid input.
It must return -1 to indicate the tp pointer is to invalid memory.
All system calls indicate invalid pointer arguments in that way, and
this one is not special.
[EFAULT] An
