[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Limit of 27 messages sequences per folder

From: Paul Vixie
Subject: Re: [Nmh-workers] Limit of 27 messages sequences per folder
Date: Wed, 27 Mar 2013 05:14:39 -0700
User-agent: Postbox 3.0.7 (Windows/20130120)

Jerrad Pierce wrote:
> ...
> It might offend one's engineer sensibilities that sequences
> are limited, but on the flip-side there's something to be
> said for simplicity and the fact that the system works, no? 
> Arbitrary and low limits from older system constraints should
> be updated of course, but why rejigger everything for a use
> case that nobody currently has? Nobody can have more than 27
> labels, and it does not seem to have been an issue. If the
> ceiling can be doubled without effort that makes sense though.

i looked at the code in question, with the thought of replacing it with
something more dynamic. i conclude that jerrad is right. the seqset_t
data type should be extended to have more bits in it but should remain
an integer. note that the constant "5" appears twice in mh.h, and i
recommend that the two occurrences be reversed so that the definition is
first, and that the reference be replaced by a reference to the macro name.

 * type for holding the sequence set of a message
typedef unsigned int seqset_t;

 * Determine the number of user defined sequences we
 * can have.  The first 5 sequence flags are for
 * internal nmh message flags.
#define NUMATTRS  ((sizeof(seqset_t) * Nbby) - 5)

 * first free slot for user defined sequences
 * and attributes
#define FFATTRSLOT  5

as to replacing it with a more dynamic structure, this won't save us
anything in the best case, since we'd be replacing an int with a
pointer, where a pointer will actually be as large as a long int on most
modern systems. "struct msgs" has one seqset_t to describe the
publicness of each sequence, and then a dynamic array of seqset_t's to
describe the sequence membership status of each message in the message
set. replacing this with an array of pointers would only be worthwhile
if we thought someone was ever going to need more than 59 sequences in a
folder. right now there's no reason to think so. thus my recommendation
that we follow the earlier advice and make the one-line change.

sorry for the noise.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]