All of lore.kernel.org
 help / color / mirror / Atom feed
From: "George Spelvin" <linux@sciencehorizons.net>
To: andriy.shevchenko@linux.intel.com, joe@perches.com,
	linux@sciencehorizons.net
Cc: akpm@linux-foundation.org, bjorn@mork.no,
	linux-kernel@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] lib/uuid.c: eliminate uuid_[bl]e_index arrays
Date: 31 May 2016 18:05:15 -0400	[thread overview]
Message-ID: <20160531220515.17294.qmail@ns.sciencehorizons.net> (raw)
In-Reply-To: <1464730604.14627.66.camel@perches.com>

> Functions with sized array arguments are generally undesired.
> 
> Linus once wrote: (http://comments.gmane.org/gmane.linux.kernel/2031400)
> 
>     array arguments in C don't
>    actually exist. Sadly, compilers accept it for various bad historical
>    reasons, and silently turn it into just a pointer argument. There are
>    arguments for them, but they are from weak minds.
>
> Perhaps this would be better using simple pointers and without the __
>
> static int __uuid_to_bin(const char *uuid, u8 *b, const u8 *si)

I haven't looked up the full original discussion to see if this is a point
on which I disagree with Linus, but I find it useful for documentation:
this is not just a pointer to "some" bytes, this is a pointer to [LENGTH]
bytes.  It's a reminder to the caller that they'd better pass in a buffer
of the required size.

Obviosuly, it makes no actual difference to the compiler.

C99 actually has a way to say this explicitly to the compiler, but the
syntax is ugly:

static int __uuid_to_bin(const char uuid[static 36], __u8 b[static 16],
	const u8 si[static 16])

(This includes the effect of __attribute__((nonnull)).)

Further discussion at
https://hamberg.no/erlend/posts/2013-02-18-static-array-indices.html
https://stackoverflow.com/questions/3430315/what-is-the-purpose-of-static-keyword-in-array-parameter-of-function-like-char


(FWIW, another two style points which I disagre with Linus about are
that I don't mind "sizeof variable" without parens, and that I don't
mind using a bare "0" for a null pointer.  More substantially, I like
"bool" a lot more than Linus does.)

  reply	other threads:[~2016-05-31 22:05 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 [this message]
2016-06-01 12:32       ` Andy Shevchenko
2016-06-01 15:07         ` George Spelvin
2016-06-02 16:48           ` Joe Perches
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=20160531220515.17294.qmail@ns.sciencehorizons.net \
    --to=linux@sciencehorizons.net \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bjorn@mork.no \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --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.