On 30/10/2019 23.16, Ilya Dryomov wrote: > On Wed, Oct 30, 2019 at 9:35 PM Rasmus Villemoes > <linux@xxxxxxxxxxxxxxxxxx> wrote: >> >> On 30/10/2019 17.19, Ilya Dryomov wrote: >>> On Thu, Oct 24, 2019 at 11:49 AM David Howells <dhowells@xxxxxxxxxx> wrote: >>>> /* >>>> - * We use a start+len construction, which provides full use of the >>>> - * allocated memory. >>>> - * -- Florian Coosmann (FGC) >>>> - * >>>> + * We use head and tail indices that aren't masked off, except at the point of >>>> + * dereference, but rather they're allowed to wrap naturally. This means there >>>> + * isn't a dead spot in the buffer, provided the ring size < INT_MAX. >>>> + * -- David Howells 2019-09-23. >>> >>> Hi David, >>> >>> Is "ring size < INT_MAX" constraint correct? >> >> No. As long as one always uses a[idx % size] to access the array, the >> only requirement is that size is representable in an unsigned int. Then >> because one also wants to do the % using simple bitmasking, that further >> restricts one to sizes that are a power of 2, so the end result is that >> the max size is 2^31 (aka INT_MAX+1). > > I think the fact that indices are free running and wrap at a power of > two already restricts you to sizes the are a power of two, Ah, yes, of course. When reducing indices mod n that may already have been implicitly reduced mod N, N must be a multiple of n for the result to be well-defined. Rasmus
