From owner-freebsd-threads@freebsd.org Wed Jan 27 04:07:46 2016 Return-Path: Delivered-To: freebsd-threads@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 96F4EA6EE3C for ; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) 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 6EA501181 for ; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6C829A6EE3A; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) Delivered-To: threads@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 6B8C2A6EE38; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28A12117E; Wed, 27 Jan 2016 04:07:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ob0-x233.google.com with SMTP id is5so158664792obc.0; Tue, 26 Jan 2016 20:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8c8cFMzpu1Eo5kd5Vi84Y1/ndIb2zqmERWEkC0iSDPo=; b=I703BzXsF4pQPHe1Ko8m/B2TJpxs3/dXcHbiRIKhC3rbXIe7sMaew6PHGaFL1f77d0 1AeCRVs0NStlQKqJ+Fz+nphp1Lh1e6EmoEeMpUdwce0YYJ0C3EfqF65haYlsequDAVKL mT7VEcqluhHK1p52WSMVEic8UIULeDCw/L2D7fONWoRzTv9p9GgXEfJi7S5fyG87Xibi lKpWxbSNmVPPPdC0AuKMbvPqGEr6L0IRnIl3wOO60Tn5D2lmMbuMZjrV4PUQi0AMS96o 6iE1PSPP/soewfXWcWCu8V4PFi4BKI9AOcIEC9iCxTOP5YL/pPiUbFQzSpH6Ge5ml4BP gn7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8c8cFMzpu1Eo5kd5Vi84Y1/ndIb2zqmERWEkC0iSDPo=; b=C0raulsV0wlAt6FMYXxitYMBC7Lfy86eX1Ajtc/5aTnqLg3F9hVcvEOARRjhU5Oz9D RyfXxL8soQUnOFtmWQtJ4AGxbnSjD9jnRDwbu7Uk0HhjMTvfdK4KJk0G1tehBwcU9fKv 2NxG9fKLfYbGm/wP9HREMC4pT8NNjNnKP1LMOwOqk6VRMZyQ+IFqs1k6/p5ZIflDOVLu sGL+zB+0WMdBOvH6coSPh+1WfKBAALBQPtG4pLsu3NOdDRVxbb1lD6T10ENzxMzi0hpE ZnC4fdj54eXkOkOcf4TmeePwxX/Wa5XbAx+3d6thlQ5FX58vvuYxR/TvAQYP7aPcEKpi 42ww== X-Gm-Message-State: AG10YOQCe7wMUIifo18SJbDGjGhA1kTrb6l3VYnOKYEU8jVMqaUO1tgZ3qXGzJVCcXdzTv6Px1j7oDWeXWbAIA== MIME-Version: 1.0 X-Received: by 10.182.116.200 with SMTP id jy8mr21254020obb.35.1453867665444; Tue, 26 Jan 2016 20:07:45 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.202.89.130 with HTTP; Tue, 26 Jan 2016 20:07:45 -0800 (PST) In-Reply-To: <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> <20160127132558.W985@besplex.bde.org> Date: Tue, 26 Jan 2016 20:07:45 -0800 X-Google-Sender-Auth: bF99goyZzGwjIdS4teqKAUU-7Kg Message-ID: Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? From: Kevin Oberman To: Bruce Evans Cc: Gary Jennejohn , Daniel Eischen , threads@freebsd.org, Boris Astardzhiev , Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 04:07:46 -0000 Since this has become a debate on programming style, it seem appropriate to mention that Edward Yourdan passed away last Tuesday. For those too young to recognize the name, he was the developer of modern structured programming. He did recognize the style rules are important, but not iron-clad. Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans wrote: > 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 > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >