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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers