[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some snippets from make381
From: |
Markus Mauhart |
Subject: |
Re: some snippets from make381 |
Date: |
Wed, 9 Mar 2005 23:53:25 +0100 |
> 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.