Does FreeBSD have sendmmsg or recvmmsg system calls?

[Alfred Perlstein]

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.

-Alfred