The replica utilities use an avl tree to store sets of filenames and attributes. When new trees are created, the function "mkavltree" is called. It's argument is the comparison routine "entrycmp" in db.c. "entrycmp" in turn uses "strcmp" to do it's donkey work, and returns that value directly. The avl code requires that it's comparison function returns -1, 0 or 1. Strcmp is guaranteed only to return an integer whose sign reflects the comparison result. Whilst on the 386 strcmp does indeed return -1, 0 or 1, on the arm platform this isn't necessarily the case, leading to bad things.
in db.c: 60a61 > int r; 64c65,66 < return strcmp(ea->name, eb->name); --- > r = strcmp(ea->name, eb->name); > return r > 0 ? 1 : r < 0 ? -1 : 0; Rod ;----------------- PS. Subsequently I wondered if this problem occured elsewhere in the system. The only other place I can find avl trees being used is in venti/copy. The actual avl library is used here, rather than the nearly-the-same-as-the-library file that the replica utilities use. The function "scoretreecmp" does seem to me to have the potential to return non (-1,0,1) values. The return value can derive not only from memcmp, but also from the difference between the two score types. As it happens "memcmp" is "safe" for both 386 and arm, and I am guessing that the latter comparison rarely happens. I also note anyway that the avl tree is only created and used if the undocumented -m option is specified on the command line. It seems that the chance of provoking the problem here is small...
