>That happens on both 32- and 64-bit Linux. So as of right >now, with your new locking code, I don't need to worry about >losing any sequence information, right?
I believe so (fun fact; the old locking code released the lock on the file before it called fclose(). Whoops). But when you say "64-bit" Linux, what does that mean, exactly? Do they have different compiler memory models? That's the real issue here. On your 32-bit system, is it ILP32 or LP64? >I seqset_t is changed to an 8-byte long on 64-bit Linux, >that would no longer be true, right? That is true. Well, unless your 32-bit linux is an LP64 system; some quick research suggests that it is not clear what the ABI is on those systems (they may be IP32L64). >It looks like it'd be easy to propagate the error back to >folder_read(). Every caller of that checks its return >value. I don't understand how "more correct" can be "wrong". Think about the consequences here. If folder_read() returns an error, that means nmh stops working; hence the reason fixing sequence file corruption was dealt with in the first place. If nmh stops working, that means that programs like rcvstore and inc stop working, which means you stop getting mail. Clearly this was why previous iterations of the code erred on the side of silently eating errors. And let's think about the situation where that would occur. You can't use the standard tools to add those sequences, unless you've got the old-code/new-code problem. You'd have to work at it. --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
