Bugzilla

(In reply to Jorg K (GMT+1) (PTO to 26th Jan 2020, sporadically reading bugmail) from comment #17)
> There's also debugging code in the patches in bug 1242030, mostly like `fprintf(stderr, "(debug) ...`. Personally I'd add as little debug as possible, and I'm wondering what the `#ifdef USEVALGRIND` is about. As far as I can see, that's not a flag the environment supports, so there is no point adding that code.

Good catch.
ifdef USEVALGRIND is a cruft left over when I used valgrind-supplied library routines to check the "definedness" of a memory location.
I no longer use it in this patch. So I am creating a new local patch in which I took it out and also changed one other |ifdef USEVALGRIND| to |ifdef DEBUG|.
The patched source tree was checked by |../mach clang-flow -p ...|.
 

As for  bug 1242030, I have tried a bit locally to reduce the open-coded debug printf statement by creating a few macros and functions so as not to clutter up the original source code superficially, but the problem is that there are SIMPLY TWO FEW CHECKS for low-level I/O failures, 
I need to add the check and somehow transmits the failure status to the calling routine (and to the debugging console or human debugger) in some way or the other.: This latter dump is very important for me to analyze OSX and Windows failure because I am developing patches under linux only. Any I/O related failures that I can't reproduced under linux needs to be analyzed by dumping detailed context on tryserver runs.
Anyway, I will try a bit more in that angle.

Thank you again for your comments.

(In reply to Jorg K (GMT+1) (PTO to 26th Jan 2020, sporadically reading bugmail) from comment #17)
> There's also debugging code in the patches in bug 1242030, mostly like `fprintf(stderr, "(debug) ...`. Personally I'd add as little debug as possible, and I'm wondering what the `#ifdef USEVALGRIND` is about. As far as I can see, that's not a flag the environment supports, so there is no point adding that code.

Good catch.
ifdef USEVALGRIND is a cruft left over when I used valgrind-supplied library routines to check the "definedness" of a memory location.
I no longer use it in this patch. So I am creating a new local patch in which I took it out and also changed one other |ifdef USEVALGRIND| to |ifdef DEBUG|.
The patched source tree was checked by |../mach clang-flow -p ...|.
 

As for  bug 1242030, I have tried a bit locally to reduce the open-coded debug printf statement by creating a few macros and functions so as not to clutter up the original source code superficially, but the problem is that there are SIMPLY TWO FEW CHECKS for low-level I/O failures, 
I need to add the check and somehow transmits the failure status to the calling routine (and to the debugging console or human debugger) in some way or the other.: This latter dump is very important for me to analyze OSX and Windows failure because I am developing patches under linux only. Any I/O related failures that I can't reproduce under linux need to be analyzed by dumping detailed context on tryserver runs.
Anyway, I will try a bit more in that angle.

Thank you again for your comments.