Does FreeBSD have sendmmsg or recvmmsg system calls?

[Boris Astardzhiev]

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 at 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 at 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 at gmail.com
>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>
>> On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans <brde at 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 at freebsd.org> wrote:
>>>>
>>>> On Tue, 26 Jan 2016, Gary Jennejohn wrote:
>>>>>
>>>>> On Tue, 26 Jan 2016 09:06:39 -0800
>>>>>> Luigi Rizzo <rizzo at iet.unipi.it> wrote:
>>>>>>
>>>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov
>>>>>>> <kostikbel at 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 at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>>>
>>
>>
>