Date: Wed, 27 Jan 2016 12:19:09 +0200 From: Boris Astardzhiev <boris.astardzhiev@gmail.com> To: Kevin Oberman <rkoberman@gmail.com> Cc: Bruce Evans <brde@optusnet.com.au>, Gary Jennejohn <gljennjohn@gmail.com>, Daniel Eischen <deischen@freebsd.org>, threads@freebsd.org, Luigi Rizzo <rizzo@iet.unipi.it>, "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: Does FreeBSD have sendmmsg or recvmmsg system calls? Message-ID: <CAP=KkTwqYLkUvd-7wiCWndvFQX4D3qw8q18LhxjofHQnUrKKXA@mail.gmail.com> In-Reply-To: <CAP=KkTwEGVhKxSmZUDsq4hJ9K_nHrO9di1maS7zVn2CNX8TqAg@mail.gmail.com> References: <20160118140811.GW3942@kib.kiev.ua> <CAP=KkTzLCOnJVqt5F3ZuuZUiwkmWcne2Ynpi6-daE2jTzSBtfw@mail.gmail.com> <20160120073154.GB3942@kib.kiev.ua> <CAP=KkTx3dAUuSBrJiwNAAe%2BhHSG4j5Qp7sAcgtOgmVi8a12k1A@mail.gmail.com> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <CAP=KkTw=ML=oPo2OgFfmor_nsL3om6HvmTQjKNMrOiU_dmWc2g@mail.gmail.com> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <CAP=KkTyHG9Rb%2BnrDC1TDxzjUQFca9NkVp8Suo1c_-C00RUtkuQ@mail.gmail.com> <20160126134005.GD3942@kib.kiev.ua> <CA%2BhQ2%2BivWYJMDUwzdZGW88-mWzSVfPzX212sOFVmxxN0hpZ%2BQQ@mail.gmail.com> <20160126182543.64050678@ernst.home> <Pine.GSO.4.64.1601261743450.12995@sea.ntplx.net> <20160127013145.36f2aaef@ernst.home> <20160127132558.W985@besplex.bde.org> <CAN6yY1snu5YkXbTTHku4OAE6UyoQ5ibyM79KgHUN2dzRgvXSuA@mail.gmail.com> <CAP=KkTwEGVhKxSmZUDsq4hJ9K_nHrO9di1maS7zVn2CNX8TqAg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
ba>Is it possible that ppoll() doesn't return an error and yet revents
ba>have set either POLLERR or POLLHUP or POLLNVAL?
Apart from timeout.
On Wed, Jan 27, 2016 at 12:14 PM, Boris Astardzhiev <
boris.astardzhiev@gmail.com> wrote:
> Hello,
>
> I've made a few changes in the patch as recommended here starting with
> the switch to ppoll(). I have a question since it's not quite clear to me
> as written
> in the manpage. Is it possible that ppoll() doesn't return an error and
> yet revents
> have set either POLLERR or POLLHUP or POLLNVAL?
>
> See patch and comments are again welcomed.
>
>
> On Wed, Jan 27, 2016 at 6:07 AM, Kevin Oberman <rkoberman@gmail.com>
> wrote:
>
>> 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 <brde@optusnet.com.au>
>> wrote:
>>
>>> On Wed, 27 Jan 2016, Gary Jennejohn wrote:
>>>
>>> On Tue, 26 Jan 2016 17:46:52 -0500 (EST)
>>>> Daniel Eischen <deischen@freebsd.org> wrote:
>>>>
>>>> On Tue, 26 Jan 2016, Gary Jennejohn wrote:
>>>>>
>>>>> On Tue, 26 Jan 2016 09:06:39 -0800
>>>>>> Luigi Rizzo <rizzo@iet.unipi.it> wrote:
>>>>>>
>>>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov
>>>>>>> <kostikbel@gmail.com> 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"
>>>
>>
>>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP=KkTwqYLkUvd-7wiCWndvFQX4D3qw8q18LhxjofHQnUrKKXA>