From owner-freebsd-net@freebsd.org Wed Jan 27 22:29:28 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 397DBA6F6B9 for ; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2346E1243 for ; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 20134A6F6B7; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04D42A6F6B6; Wed, 27 Jan 2016 22:29:28 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id E1B5C1241; Wed, 27 Jan 2016 22:29:27 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8001:cee1:c548:2788:e3cb:8a45]) by elvis.mu.org (Postfix) with ESMTPSA id 779D4345A921; Wed, 27 Jan 2016 14:29:27 -0800 (PST) Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? To: Luigi Rizzo , gljennjohn@gmail.com References: <20160118140811.GW3942@kib.kiev.ua> <20160120073154.GB3942@kib.kiev.ua> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <20160126134005.GD3942@kib.kiev.ua> <20160126182543.64050678@ernst.home> <20160127013145.36f2aaef@ernst.home> Cc: Daniel Eischen , threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" From: Alfred Perlstein Organization: FreeBSD Message-ID: <56A944C6.1040603@freebsd.org> Date: Wed, 27 Jan 2016 14:29:26 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 22:29:28 -0000 On 1/26/16 4:39 PM, Luigi Rizzo wrote: > On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn wrote: >> On Tue, 26 Jan 2016 17:46:52 -0500 (EST) >> Daniel Eischen wrote: >> >>> On Tue, 26 Jan 2016, Gary Jennejohn wrote: >>> >>>> On Tue, 26 Jan 2016 09:06:39 -0800 >>>> Luigi Rizzo wrote: >>>> >>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov >>>>> wrote: >>>>>> On Mon, Jan 25, 2016 at 11:22:13AM +0200, Boris Astardzhiev wrote: >>>>>>> +ssize_t >>>>>>> +recvmmsg(int s, struct mmsghdr *__restrict msgvec, size_t vlen, int flags, >>>>>>> + const struct timespec *__restrict timeout) >>>>>>> +{ >>>>>>> + size_t i, rcvd; >>>>>>> + ssize_t ret; >>>>>>> + >>>>>>> + if (timeout != NULL) { >>>>>>> + fd_set fds; >>>>>>> + int res; >>>>>> Please move all local definitions to the beginning of the function. >>>>> This style recommendation was from 30 years ago and is >>>>> bad programming practice, as it tends to complicate analysis >>>>> for the human and increase the chance of improper usage of >>>>> variables. >>>>> >>>>> We should move away from this for new code. >>>>> >>>> Really? I personally find having all variables grouped together >>>> much easier to understand. Stumbling across declarations in the >>>> middle of the code in a for-loop, for example, takes me by surprise. >>>> >>>> I also greatly dislike initializing variables in their declarations. >>>> >>>> Maybe I'm just old fashioned since I have been writing C-code for >>>> more than 30 years. >>> +1 >>> >>> Probably should be discouraged, but allowed on a case-by-case >>> basis. One could argue that if you need to declaration blocks >>> in the middle of code, then that code is too complex and should >>> be broken out into a separate function. >>> >> Right. >> >> And code like this >> >> int func(void) >> { >> int baz, zot; >> [some more code] >> if (zot < 5) >> { >> int baz = 3; >> [more code] >> } >> [some more code] >> } >> >> is even worse. The compiler (clang) seems to consider this to >> merely be a reinitialization of baz, but a human might be confused. > oh please... :) > > This is simply an inner variable shadowing the outer one > (which is another poor practice, flagged with -Wshadow ). > When you exit the scope you get the external variable > with its value, as you can see from the following code. > > #include > int main(int ac, char *av[]) > { > int baz = 5; > printf("1 baz %d\n", baz); > { > int baz = 3; > printf("2 baz %d\n", baz); > } > printf("3 baz %d\n", baz); > return 0; > } > I agree wholeheartedly with Luigi. I am also surprised that shadowed variable warnings was not more widely understood. It's time to move forward and make the code more readable and maintainable. Having scoped variables just makes sense. It's true that if you see very many of them, then it's likely time to introduce separate functions, but only in extreme cases, not on a case-by-case basis. -Alfred