Date: Mon, 31 Aug 1998 18:54:41 +0200 From: Stefan Eggers <seggers@semyam.dinoco.de> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Stefan Eggers <seggers@semyam.dinoco.de>, Kris Kennaway <kkennawa@physics.adelaide.edu.au>, freebsd-current@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: IPFW showing extra lines Message-ID: <199808311654.SAA22726@semyam.dinoco.de> In-Reply-To: Your message of "Mon, 31 Aug 1998 11:03:39 EDT." <199808311503.LAA26383@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> No -- you missed the point of the comment above. The definition of
> the API is that we always return the size of the total amount of data
> we have, regardless of what the size of the user's buffer is --
Sure? I took a look at the source of ipfw(8) and there it looks like
it expects it to be the size of the data returned or it will access data
outside the allocated buffer. The latter would be pretty bad of course.
getsockopt(2) says pretty much the same if I understand it correctly:
for the requested option(s) are to be returned. For getsockopt(), optlen
is a value-result parameter, initially containing the size of the buffer
pointed to by optval, and modified on return to indicate the actual size
of the value returned. If no option value is to be supplied or returned,
I think the actual size of the returned value is the size of the result
we copied to user space. Otherwise the wording has to be revised (made
more precise) and ipfw fixed.
Stefan.
--
Stefan Eggers Lu4 yao2 zhi1 ma3 li4,
Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1.
51109 Koeln
Federal Republic of Germany
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808311654.SAA22726>