From: Joe Perches <joe@perches.com>
To: George Spelvin <linux@sciencehorizons.net>,
andriy.shevchenko@linux.intel.com
Cc: akpm@linux-foundation.org, bbjorn@mork.no,
linux-kernel@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] lib/uuid.c: eliminate uuid_[bl]e_index arrays
Date: Thu, 02 Jun 2016 09:48:11 -0700 [thread overview]
Message-ID: <1464886091.14627.100.camel@perches.com> (raw)
In-Reply-To: <20160601150705.27355.qmail@ns.sciencehorizons.net>
On Wed, 2016-06-01 at 11:07 -0400, George Spelvin wrote:
> On Wed, 01 Jun 2016 at 15:32:47, Andy Shevchenko wrote:
> > On Tue, 2016-05-31 at 14:36 -0700, Joe Perches wrote:
> > > On Tue, 2016-05-31 at 16:31 -0400, George Spelvin wrote:
> > > > -static int __uuid_to_bin(const char *uuid, __u8 b[16], const u8
> > > > ei[16])
> > > > +static int __uuid_to_bin(const char uuid[36], __u8 b[16], const u8
> > > > si[16])
> > > Functions with sized array arguments are generally undesired.
> > That function follows existing UUID API. Since we have now it
> > consolidated in one place someone may fix it eventually.
> Just to clarify:
>
> int foo(char *);
> int foo(char *floccinaucinihilipilifcation);
> int foo(char *p);
> int foo(char p[]);
> int foo(char []);
> int foo(char p[1]);
> int foo(char p[999999999]);
>
> are all the exact same declaration. There is no API change; the only
> difference is stylistic. (Try it! Copy them to a .c file and
> compile it. Observe the lack of conflicting declaration warnings.)
>
> Although the compiler doesn't care, I happen to prefer to include
> parameter names for the benefit of someone reading the header files.
>
> For the same reason, if the pointer is to the start of an array with
> definite length (that's not 1), I prefer to use the array form showing
> that length.
>
> But it's a matter of style, not substance, either way.
I believe the substantive bit of the argument is the ability
to misunderstand that sizeof(argument with size char[999])
is not 999 but is sizeof(*).
next prev parent reply other threads:[~2016-06-02 16:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1464594339.27624.45.camel@linux.intel.com>
2016-05-30 17:32 ` [PATCH] lib/vsprintf.c: Further simplify uuid_string() George Spelvin
2016-05-31 20:31 ` [PATCH] lib/uuid.c: eliminate uuid_[bl]e_index arrays George Spelvin
2016-05-31 21:36 ` Joe Perches
2016-05-31 22:05 ` George Spelvin
2016-06-01 12:32 ` Andy Shevchenko
2016-06-01 15:07 ` George Spelvin
2016-06-02 16:48 ` Joe Perches [this message]
2016-06-01 19:58 ` Andrew Morton
2016-06-01 20:13 ` Andy Shevchenko
2016-06-03 11:17 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1464886091.14627.100.camel@perches.com \
--to=joe@perches.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bbjorn@mork.no \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@sciencehorizons.net \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.