On Saturday 14 April 2012 17:22:06 Michael Kerrisk (man-pages) wrote: > The count arguments and > .IR local_iov > are checked before doing any transfers. > If the counts are too big, or > .I local_iov > is invalid, > or the addresses refer to regions that are inaccessible to the local > process, none of the vectors will be processed > and an error will be returned immediately. to be clear, the arrays themselves are checked to see if they point to valid memory, as are the count values, before the transfer takes place. so if local_iov/remote_iov are NULL or similarly invalid, nothing happens. in practice, this generally equates to the same thing, but there is a slight edge case -- if the remote_iov array is mostly valid, but the remote count value causes it to spill into invalid memory, nothing will be processed. note that i'm talking about the storage of the elements themselves and not the memory they point to. but maybe being super pedantic here isn't necessary ... > Note, however, that these system calls do not check the memory regions > in the remote process until just before doing the read/write. > Consequently, a partial read/write may result if one of the any mention of a partial read/write should point to the text clarifying what that means (perhaps something as simple as "see RETURN VALUE for more info". > Does that not make better sense? it does > Perhaps I'm too clogged up with a cold, but I couldn't draw an answer > to the question " does "a single iovec element" here apply to the > remote iovec elements, the local iovec elements, or both?" from your > reply. wrt partial transfers, remote only afaict. this is by virtue of nothing being transferred at all if any of the local elements are invalid. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
