> > :Well, since a server specifies the maximum file size it can > > :handle, it seems good form to check for that in the client. > > :(Although I'd agree that a server shouldn't crash if a read/write > > : that goes beyond that limit.) > > : > > :Also, as Matt notes, off_t is signed. As such, it looks to me like > > :the check could mess up if uio_offset it right near > > 0x7fffffffffffffff, > > :so that uio->ui_offset + uio->uio_resid ends up negative. I think > > the > > :check a little above that for uio_offset < 0 should also check > > :uio_offset + uio_resid < 0 to avoid this. > > : > > :rick > > > > Yes, though doing an overflow check in C, at least with newer > > versions > > of GCC, requires a separate comparison. The language has been > > mangled > > pretty badly over the years. > > > > > > if (a + b < a) -> can be optimized-out by the compiler > > > > if (a + b < 0) -> also can be optimized-out by the compiler > > > > x = a + b; > > if (x < a) -> this is ok (best method) > > > > x = a + b; > > if (x < 0) -> this is ok > > Ok, thanks. I'll admit to being an old K+R type guy.
> > my question, badly written, was why not let the underlaying fs (ufs, > zfs, etc) > have the last word, instead of the nfsclient having to guess? Is there > a problem in sending back the error? > Well, the principal I try and apply in the name of interoperability is: 1 - The client should adhere to the RFCs as strictly as possible 2 - The server should assume the loosest interpretation of the RFCs. For me #1 applies. ie. If a server specifies a maximum file size, the client should not violate that. (Meanwhile the server should assume that clients will exceed the maximum sooner or later.) Remember that the server might be a Netapp, EMC, ... and those vendors mostly test their servers against Linux, Solaris clients. (I've tried to convince them to fire up FreeBSD systems in-house for testing and even volunteered to help with the setup, but if they've done so, I've never heard about it. Their usual response is "come to connectathon". See below.) Here's an NFSv4.0 example: - RFC3530 describes the "dircount" argument for Readdir as a "hint of the maximum number of bytes of directory information" (in 4th para of pg 191). One vendor ships an NFSv4 client that always sets this value to 0. Their argument is that, since it is only a "hint" it can be anything they feel like putting there. (Several servers crapped out because of this in the early days.) Part of the problem is that I am not in a position to attend the interoperability testing events like www.connectathon.org, where these things are usually discovered (and since they are covered under an NDA that attendies sign, I don't find out the "easy way" when problems occur). rick _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
