>> I double-checked my earlier assertion, and it turns out I was correct. >> The "extra" sequence(s) silently gets ignored upon read by older utilities >> and will be deleted when the sequence file is updated. Is that Something >> Evil? Depends on your perspective, I suppose. I think it's behavior >> I could live with. > >You got some way to ensure that the Unseen sequence is in the first 27? :)
I was curious about that, so I looked; the answer is "no". I guess I was thinking about the general Unix idea that you should give the user enough rope to hang his-or-her-self if they so desire. Let me ask a counter-question. Given Norm's request, what is your answer? Do nothing? Does that mean we cannot ever raise the sequence limit? We actually don't enforce this anywhere; if you compile on an ILP64 system, you'll already have more than 27 sequences supported. I don't know how common ILP64 systems are, though. My point is that we never really had any explicit guarantees as to what happens if you have more than 27 sequences. I admit that I don't have a great answer for this situation. Norm writes: >> The attractiveness of Norm's suggestion is that it's literally a >> one-line change. > >Not counting changing the man page for mark. Hm. You know, I just looked at that. Turns out that this was a problem already: Only a certain number of sequences may be defined for a given folder. This number is usually limited to 27 (11 on small systems). Wow, THAT entry sure is dated. 16-bit ints! Although I wonder if any of those systems with 16-bit ints had NFS; seems unlikely. But clearly the "MH way" was to silently discard sequences that exceeded the per-folder limit. That doesn't mean that it should always be the way, of course. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
