Andrew Morton wrote:
> Does the spec say what the OS should do if (ts_nsec => 1e9)?

Yes, return EINVAL.  We already do this.  It's just that now we have to
recognize two special values.


> OK, so there's no collision on ts_nsec if unnormalised timespecs are
> disallowed.

Indeed, that's the basis of using the special values.

I chose the values of the constants so that they are a) out of the way
of valid values and b) don't have to be adjusted for 32-bit compat code.


> But there's a potential collision on ts_sec?  Do we know what date that
> corresponds to?

No, there is no collision.  The tv_sec value is relevant.  The
UTIME_OMIT and UTIME_NOW value refers to the atime/mtime respectively,
not just the tv_nsec field of either.  It makes no sense to just set
tv_sec, the tv_nsec value would be basically random.

In my patch I'm testing that tv_sec is zero in case any of the special
values is used in the corresponding tv_nsec field.  That's more than the
standard currently requires but I think it's better and I try to get the
standard proposal changed.  If this doesn't happen I'll make appropriate
changes at userlevel for the "strictly POSIX" mode.


> Do you have a testcase app which can be used by arch maintainers?

Attached here.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖