Skip site navigation (1)Skip section navigation (2)
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>