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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1248364937.24021.725.camel@nimitz>
Date:	Thu, 23 Jul 2009 09:02:17 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	Oren Laadan <orenl@...columbia.edu>
Cc:	akpm@...ux-foundation.org, vda.linux@...glemail.com,
	containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, menage@...gle.com
Subject: Re: [RFC][PATCH] flexible array implementation v3

On Thu, 2009-07-23 at 11:44 -0400, Oren Laadan wrote:
> Probably premature, but -- I wonder if it's worth adding interfaces to:
> 
> * copy a range of elements at once (perhaps to/from regular array ?
> or userspace ? -- depending on potential users)

I can see this making some sense, especially if you're dumping a bunch
of stuff out to userspace and don't want to worry about page boundaries,
etc...  Or, if you have a ton of stuff to copy and some of the
flex_array overhead is getting in the way.  I'm not opposed to it, but I
think I'd want to see a user first to make sure I got the implementation
right.

> * (macro ?) iterate through elements (better have it ready for users
> of flex_array before, than convert their code later on)

I've thought about this, but I don't think there's much advantage to
doing it.  It obfuscates things without any real gain in simplicity.  We
have LIST_FOR_EACH() because containerof() and some of the typing is a
little non-obvious.  But, here, I think it's mostly dummy-proof:

We need a 'tmp' variable here because unlike list traversal, there's no
position implied in the variables.  So, we're looking at (with a new
macro):

	int tmp;
	FA_FOR_EACH(fa, var, tmp)
		foo(var);

vs.

	int i;
	for (i = 0; i < fa->total_nr_elements; i++)
		foo(flex_array_get(fa, i));

The macro *looks* cleaner, but I don't think it really buys us much.

-- Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ