GNU bug report logs -
#77840
Testing diffutils 3.12 on PPC Mac OS X 10.4.11, Tiger, produces so many failures
Previous Next
Full log
Message #62 received at 77840 <at> debbugs.gnu.org (full text, mbox):
> Am 13.06.2025 um 19:14 schrieb Paul Eggert <eggert <at> cs.ucla.edu>:
>
> On 2025-06-13 01:03, Peter Dyballa wrote:
>> Another question seems to be, why is the null pointer used when calling fwrite()? A check should avoid this, rather early, and report or set some failure status…
>
> No, that would be a bad way to "fix" things. We should find the real problem and fix it, not paper over it.
Correct, the actual cause for an error condition that was not thought of should be determined.
But, when this case is found and fixed, one would again *assume* that no null pointer will be passed to fwrite(). Until a new case appears.
There is so much code that checks for particular circumstances (could be repeatedly – isn't there a large struct for every file of a set to diff/comp it that could provide "regular file", "unreadable", "binary", "directory", etc. condition from first check on?), so there could be as well one more, final, check. And then write to stderr? The differences, or equal text blocks, seem to be determined correctly, so why throw that data away? This is not economical.
I think debugging will continue a few days, probably. A bit confusing is that functions are called from a handful of different files and Gdb is jumping around… At least I think that when coming close to the failure I'd have the series of breakpoints decimated, not stopping at each function call and stepping into it!
--
Greetings
Pete
If it dies, it's biology. If it blows up, it's chemistry. If it doesn't work, it's physics.
– University washroom sgraffito
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.