From owner-freebsd-net@freebsd.org Thu Jan 28 00:43:26 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 E3E41A6F61A for ; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@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 CAD3B19EC for ; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C9573A6F617; Thu, 28 Jan 2016 00:43:26 +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 C8CC8A6F616; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0E4419EA; Thu, 28 Jan 2016 00:43:26 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u0S0hIuW028478; Wed, 27 Jan 2016 19:43:18 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 27 Jan 2016 19:43:18 -0500 (EST) Date: Wed, 27 Jan 2016 19:43:18 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Alfred Perlstein cc: Luigi Rizzo , gljennjohn@gmail.com, threads@freebsd.org, Boris Astardzhiev , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <56A944C6.1040603@freebsd.org> Message-ID: 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> <56A944C6.1040603@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Thu, 28 Jan 2016 00:43:27 -0000 On Wed, 27 Jan 2016, Alfred Perlstein wrote: > > > 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. -1 It certainly doesn't make it more readable for me. It seems like it is done out of sheer laziness as opposed to structuring the code better. -- DE