I think the latest C++ standard makes null distinct from zero too. Can something like valgrind be used to detect incorrect zero/null tests? Otherwise we will be relying totally on grep.
Also, better check that we don't #define NULL in the codebase somewhere, like old code used to do. Also, better add an assert / production runtime check: if (NULL != 0 || !(NULL == 0)) then show warning to indicate that wmaker may not work on the platform properly. On 24 February 2012 16:46, Doug Barton <[email protected]> wrote: > On 02/23/2012 23:39, Paul Harris wrote: > > If that patch worked, then that looks like undefined behaviour. > > What triggered me to think about the change to logical negation turns > out to be what you could consider "a FreeBSD problem" after all. :) I > know that in some operating systems (and I believe all/most Linux'es?) > NULL is defined to be numeric 0, so equating them is safe to do. FreeBSD > doesn't do that, so it isn't safe. (Please note, I'm not trying to start > a "whose interpretation of the C standard is more correct" fight, I'm > just saying that FreeBSD does it differently than some/many others do.) > > Meanwhile, I tested that change with and without --dont-restore and it > worked as expected in both cases, so that change should go into the > repo. On a more general note, if there are any other places where 'foo > == 0' is being used where logical negation is intended, especially when > foo can be null, they should also be fixed. A quick grep of the new code > (minus str*cmp of course) indicated too many places for me to trace the > code paths myself, sorry. But changing this would definitely make the > code more robust. > > FWIW, modulo some meaningless whitespace changes the code in that line > in 0.92 is the same as it is in 0.95.2, so I'm not sure what happened. I > suspect that some new #include is indirectly pulling in our _null.h. > That's not a bad thing (in fact, it's probably more correct) but the net > effect was a change in behavior. Fortunately it's easily remedied. > > > hth, > > Doug > > -- > > It's always a long day; 86400 doesn't fit into a short. > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > >
