Does FreeBSD have sendmmsg or recvmmsg system calls?

[Daniel Eischen]

On Wed, 27 Jan 2016, Alfred Perlstein wrote:

>
>
> On 1/26/16 4:39 PM, Luigi Rizzo wrote:
>> On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn <gljennjohn at gmail.com> 
>> 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.
>>>>> 
>>>>> 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.
>>> 
>>> 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.
>> oh please... :)
>> 
>> This is simply an inner variable shadowing the outer one
>> (which is another poor practice, flagged with -Wshadow ).
>> When you exit the scope you get the external variable
>> with its value, as you can see from the following code.
>>
>>    #include <stdio.h>
>>    int main(int ac, char *av[])
>>    {
>>      int baz = 5;
>>      printf("1 baz %d\n", baz);
>>      {
>>        int baz = 3;
>>        printf("2 baz %d\n", baz);
>>      }
>>      printf("3 baz %d\n", baz);
>>      return 0;
>>    }
>> 
> I agree wholeheartedly with Luigi.   I am also surprised that shadowed 
> variable warnings was not more widely understood.
>
> It's time to move forward and make the code more readable and maintainable. 
> Having scoped variables just makes sense.  It's true that if you see very 
> many of them, then it's likely time to introduce separate functions, but only 
> in extreme cases, not on a case-by-case basis.

-1

It certainly doesn't make it more readable for me.  It seems
like it is done out of sheer laziness as opposed to structuring
the code better.

-- 
DE