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
|