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.astardzh...@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 <rkober...@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: rkober...@gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>
>> On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans <b...@optusnet.com.au>
>> wrote:
>>
>>> On Wed, 27 Jan 2016, Gary Jennejohn wrote:
>>>
>>> On Tue, 26 Jan 2016 17:46:52 -0500 (EST)
>>>> Daniel Eischen <deisc...@freebsd.org> wrote:
>>>>
>>>> On Tue, 26 Jan 2016, Gary Jennejohn wrote:
>>>>>
>>>>> On Tue, 26 Jan 2016 09:06:39 -0800
>>>>>> Luigi Rizzo <ri...@iet.unipi.it> wrote:
>>>>>>
>>>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov
>>>>>>> <kostik...@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-unsubscr...@freebsd.org"
>>>
>>
>>
>
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
