>Would that bring us to where a 32-bit executable could lose >information created by a 64-bit executable via a common sequences >file? If so, either we shouldn't do it, or should add code >to protect against the loss. It's wrong to allow silent loss.
I assume you mean "sizeof(seqset_t) == 32" (let's call that "SST32") and "sizeof(seqset_t) == 64" (SST64). We already have some SST64 systems today (but based on warnings I remember seeing on some Solaris systems, it may not work properly). The concern here is if you use an SST32 executable with a sequence file that has more than 27 sequences, right? I kinda feel that "it might affect some people in edge cases" is not good enough of a reason to not make this change. The logical conclusion from that position is that the sequence limit can never be increased. If the concern is old code, we're kinda stuck there; the old code silently ate the extra sequences and has done so for approximately forever. Also, the sequence files have been vulnerable to corruption and data loss for literally decades so it's not like it's some super-reliable data store; if you're an old MH user, you couldn't count on those things to stick around forever; if you used rcvstore, you probably couldn't count on them to last a week. I'm just trying to provide some historical perspective here; the idea of "reliable" sequence files is actually a new concept (and really, I only committed the transactional locking code a week or two ago; before that you could still have silent data loss). Also, the solution to this problem is simple: if you are in one the edge cases, simply don't make more than 27 sequences (just like now). Now, that's not to say we can't do BETTER going forward. The "silently eats extra sequences" code is in sbr/seq_read.c. Basically, the return value from seq_init() is being ignored; it returns -1 if there are too many sequences. So, if seq_init() returns -1, what do people suggest we do? Emit a warning? That would be from within a library function, which is architecturally icky. Error out like what is done now with a corrupt sequence file? Maybe more correct, but that seems wrong to me. Continue doing nothing? It would be in line with historical practice but enough people have voiced their objections to this, and it leaves me a bit unsettled as well. --Ken _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers