From owner-freebsd-net@freebsd.org Wed Jan 27 03:04:39 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 B46F8A6F809 for ; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) 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 9BBB2C0E for ; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: by mailman.ysv.freebsd.org (Postfix) id 9953CA6F807; Wed, 27 Jan 2016 03:04:39 +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 98C62A6F806; Wed, 27 Jan 2016 03:04:39 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 44004C0C; Wed, 27 Jan 2016 03:04:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 1C54342C5BF; Wed, 27 Jan 2016 14:04:30 +1100 (AEDT) Date: Wed, 27 Jan 2016 14:04:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Gary Jennejohn cc: Daniel Eischen , Boris Astardzhiev , threads@freebsd.org, Luigi Rizzo , "freebsd-net@freebsd.org" Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? In-Reply-To: <20160127013145.36f2aaef@ernst.home> Message-ID: <20160127132558.W985@besplex.bde.org> 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=PfoC/XVd c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=0JCmQBZd7s8qsGVShdUA:9 a=CjuIK1q_8ugA:10 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 03:04:39 -0000 On Wed, 27 Jan 2016, 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. +1 I used to program in a strict version of the "new" style 25-30 years ago, but learned better. In the strict version, every variable must have minimal scope, so squillions of inner blocks are needed to limit the scopes. Some deeply nested of course. This is a good obfuscation. It even breaks -Wshadow by letting you have unrelated variables named 'i' that don't shadow each other because their scope is limited. Such variables are good in separate functions but not in the same function. Understanding the code to see that the variables are actually unrelated requires counting more braces than usual. If you don't do this strictly then you get a random style with some variables declared at the top and some in inner blocks for mostly historical reasons. A strict style with all of the variables at the top is much easier to write and read. >>> 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. Lots of inner blocks are good for both making simple code look complex and making it easier to write the complex code in the same function, at least if you use a tiny indentation so that you can have 40 levels of indentation without needing a 500-column terminal. > 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. No, that is a different baz, and is warned about by Wshadow. > Something like for (int i = 0; i < 2; i++) is IMHO OK. Except it is C++ style which is so forbidden that style(9) doesn't know that it needs a rule to forbid it. The worst is C++ style that doesn't limit the scope -- a bunch of variables at the top and then somewhere in the middle of the function another variable is needed and it is declared at top level of the function scope. I sometimes do this when in a hurry. The strict K&R-C90 style requires opening an inner block to do little more than hold the declaration and then (re)indenting and (re)formatting all the code in the inner block. The C++ style reduces writability and readability in a different way. It doesn't cause excessive indentation but it doesn't limit the scope much differently than putting all the declarations at the top. At least the reader can find the declarations easily when they are at the top. Bruce