Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jan 2016 16:39:00 -0800
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        gljennjohn@gmail.com
Cc:        Daniel Eischen <deischen@freebsd.org>, threads@freebsd.org,  Boris Astardzhiev <boris.astardzhiev@gmail.com>, "freebsd-net@freebsd.org" <net@freebsd.org>
Subject:   Re: Does FreeBSD have sendmmsg or recvmmsg system calls?
Message-ID:  <CA%2BhQ2%2BjcGwK69jyiU3pbO4fhcnUUgA5sWm4nidb0bmGp04OD7A@mail.gmail.com>
In-Reply-To: <20160127013145.36f2aaef@ernst.home>
References:  <20160118140811.GW3942@kib.kiev.ua> <CAP=KkTzLCOnJVqt5F3ZuuZUiwkmWcne2Ynpi6-daE2jTzSBtfw@mail.gmail.com> <20160120073154.GB3942@kib.kiev.ua> <CAP=KkTx3dAUuSBrJiwNAAe%2BhHSG4j5Qp7sAcgtOgmVi8a12k1A@mail.gmail.com> <20160121093509.GK3942@kib.kiev.ua> <20160121233040.E1864@besplex.bde.org> <CAP=KkTw=ML=oPo2OgFfmor_nsL3om6HvmTQjKNMrOiU_dmWc2g@mail.gmail.com> <20160124050634.GS3942@kib.kiev.ua> <20160124100747.551f8e3f@ernst.home> <CAP=KkTyHG9Rb%2BnrDC1TDxzjUQFca9NkVp8Suo1c_-C00RUtkuQ@mail.gmail.com> <20160126134005.GD3942@kib.kiev.ua> <CA%2BhQ2%2BivWYJMDUwzdZGW88-mWzSVfPzX212sOFVmxxN0hpZ%2BQQ@mail.gmail.com> <20160126182543.64050678@ernst.home> <Pine.GSO.4.64.1601261743450.12995@sea.ntplx.net> <20160127013145.36f2aaef@ernst.home>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 26, 2016 at 4:31 PM, Gary Jennejohn <gljennjohn@gmail.com> wrote:
> On Tue, 26 Jan 2016 17:46:52 -0500 (EST)
> Daniel Eischen <deischen@freebsd.org> wrote:
>
>> On Tue, 26 Jan 2016, Gary Jennejohn wrote:
>>
>> > On Tue, 26 Jan 2016 09:06:39 -0800
>> > Luigi Rizzo <rizzo@iet.unipi.it> wrote:
>> >
>> >> On Tue, Jan 26, 2016 at 5:40 AM, Konstantin Belousov
>> >> <kostikbel@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;
  }

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BjcGwK69jyiU3pbO4fhcnUUgA5sWm4nidb0bmGp04OD7A>