Date: Tue, 17 Dec 1996 08:30:05 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: current@freebsd.org Subject: Re: Plan for integrating Secure RPC -- comments wanted Message-ID: <14804.850807805@critter.tfs.com> In-Reply-To: Your message of "Tue, 17 Dec 1996 00:38:30 EST." <199612170538.AAA01464@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199612170538.AAA01464@skynet.ctr.columbia.edu>, Bill Paul writes: > int optlen; > int optval; > int sock; > int rval; > > optlen = sizeof(optval); > rval = getsockopt(sock, SOL_SOCKET, SO_PEERUID, NULL, &optlen); > /* ^^^^ */ > /* deliberate bug: should be &optval */ > >According to the man page, getsockopt() should return EFAULT if optval >or optlen aren't within the process's address space. Well, NULL is not >within the process's address space, so I should get an error here, but >I don't. If I do something equally silly like use -1 instead of NULL, >then I get an EFAULT as expected. With NULL, the getsockopt() call doesn't >do anything, but it returns an rval of 0 and doesn't set errno. > >Looking at the getsockopt() code, it seems like it short-circuits the >uap->val (i.e. optval) == NULL case on purpose and doesn't return an >error. > >Am I nuts, or is this a bug? I belive the point is to return the length, so you can malloc sufficient storage and call again. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14804.850807805>