Does FreeBSD have sendmmsg or recvmmsg system calls?

Kevin Oberman rkoberman at
Wed Jan 27 04:07:46 UTC 2016

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

Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman at
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

On Tue, Jan 26, 2016 at 7:04 PM, Bruce Evans <brde at> wrote:

> On Wed, 27 Jan 2016, Gary Jennejohn wrote:
> On Tue, 26 Jan 2016 17:46:52 -0500 (EST)
>> Daniel Eischen <deischen at> wrote:
>> On Tue, 26 Jan 2016, Gary Jennejohn wrote:
>>> On Tue, 26 Jan 2016 09:06:39 -0800
>>>> Luigi Rizzo <rizzo at> wrote:
>>>> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov
>>>>> <kostikbel at> 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 mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at"

More information about the freebsd-threads mailing list