linux-kernel - Re: [PATCH] lib/uuid.c: eliminate uuid_[bl]e

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 02 Jun 2016 09:48:11 -0700
From:	Joe Perches <joe@...ches.com>
To:	George Spelvin <linux@...encehorizons.net>,
	andriy.shevchenko@...ux.intel.com
Cc:	akpm@...ux-foundation.org, bbjorn@...k.no,
	linux-kernel@...r.kernel.org, tytso@....edu
Subject: Re: [PATCH] lib/uuid.c: eliminate uuid_[bl]e_index arrays

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(*).