Date: Wed, 4 Jan 2006 15:24:23 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Diomidis Spinellis <dds@aueb.gr> Cc: cvs-src@FreeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, src-committers@FreeBSD.org, Diomidis Spinellis <dds@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_syscalls.c Message-ID: <20060104151121.T50198@delplex.bde.org> In-Reply-To: <43BB0D3B.10300@aueb.gr> References: <88559.1136330180@critter.freebsd.dk> <43BB0D3B.10300@aueb.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Jan 2006, Diomidis Spinellis wrote: > Poul-Henning Kamp wrote: >> In message <200601032158.k03LwMGP031138@repoman.freebsd.org>, Diomidis >> Spinellis writes: >> >>> dds 2006-01-03 21:58:22 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/kern vfs_syscalls.c Log: >>> Normalize the tv_usec part of the utimes(2) arguments to ensure >>> that a file's atime and mtime are only set to correct fractional >>> second values (0-999999000ns with the current interface). >> >> I think this is wrong. We should return EINVAL if the fractional >> part is not correct. I sent private mail saying similar things in more detail. > I saw that one coming :-) Solaris (SunOS 5.10) returns EINVAL, Mac OS X > Tiger and Linux 2.4.21 appear to ignore the field, and NetBSD 1.5 follows our > buggy behavior. POSIX is silent on the matter, and does not specify EINVAL > in the list of prescribed errno values > <http://www.opengroup.org/onlinepubs/007908799/xsh/utimes.html>. POSIX requires the error handling for many (most?) syscalls that deal with timevals (and timespecs?), but is sloppy for utimes(), perhaps because historical implementations are sloppy. FreeBSD does it for most (all?) other syscalls that deal with timevals, using mainly itimerfix() (which is mostly about error detection but not fixing) for timevals (including ones not related to itimers) and direct checks for timespecs. Direct checks take less code than calling a function to do the checks but more code than calling a function that both checks and "fixes". > On the other hand, normalization is easy, relatively efficient, follows the > letter of the standard, and will not break existing software. As a > precedent, consider that Unix traditionaly normalizes filename paths. Normalization is not so easy if you avoid overflow and sign problems in the normalization. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060104151121.T50198>