David Levine wrote: > Ken wrote: > >> M. Levinson sent me private email and pointed out that it's not QUITE >> a one-line change; some casts are needed in the sequence macros to >> prevent bit-shifts from overflowing an int. He was kind enough to >> send me patches that did that, so I'll probably integrate that today >> along with Paul's suggestions. > > 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.
there are possible MH folders for which a 64-bit executable would work, but a 32-bit executable would display warnings about too many sequences. however, this will be true for old- vs new-executables (pre and post patch) as well, and there's nothing we can do about that. interestingly, "int" is already 64 bits on some systems, so (sizeof(int) * Nbby) is already 64 there. we could replace this with a fixed array of u_char and some index-and-shift macros, sort of like "struct fd_set" in select(2). in this case the max number of sequences a message can be in would be a parameter rather than a function of int size. but it would still be fixed at compile time, thus still leading to warnings for small-set executables on a large-set folder. the code as it is is nonportable and unclean. if we're not going to fix it for all systems for all time, using malloc etc, then we should not set our aspirations much higher than they are currently. has anyone actually seen the "too many sequences" warning in practice? paul
_______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
