> Thanks Markus. I hope 50% of my list is worth some troubles during 381-release.
> You don't have a copy of GNU diff lying around on your Windows system do > you? yes, but better dont ask ... my sources last year suddenly got so much changes that you would need 1 week to filter out the few relevant parts - this is what I'm doing just now. > It's much, much simpler for me to see the changes if you send a context > (diff -c) or unified (diff -u) output. sorry, I hope you can grep meanwhile to the right position. > I'll look at your changes in more detail, but a note or two: > > mm> Bug ? Is this large enough to hold all necessary differences > mm> of type dev_t and ino_t ? If in doubt better use good old BOOL. > > I think that the compare function is supposed to give the same return > value as functions like strcmp() and memcmp(); yes, but 'result' is used not only for ISTRING_COMPARE, but for every substraction seen in this function: result = x->ctime - y->ctime; result = x->ino[0] - y->ino[0]; result = x->dev - y->dev; Currently I cant swear where to expect value truncation, but IIRC it happens 100% in theory and regulary in 64bit-practice. > Looking at the hash.c implementation I see that the compare function > actually only tests for equality today so your implementation works for > now, but still... I'm happy to let responsibility for proper usage of ISTRING_COMPARE on your shoulders, my concern is and was really the rest ;-) > mm> * lindex() is redundant. > > True, although very old systems might not have had memchr() > implementations. This is surely not urgent nor serious ... but in the long term I'd probably include (if necessary, autoconf...) a memchr-replacement instead of a function which name I (and I hope I'm not the only one) have never heard otherwise. Regards, Markus. _______________________________________________ Bug-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-make
