Follow-up Comment #7, bug #27809 (project make): Paul, thank you very much for reviewing the patch,
> First you mention compiler warning fixes for UNIX, but > none of the changes you mention fix any warnings I see > on my UNIX tests (different platforms but using gcc -Wall > on all of them). Which ones do you see? Hmm, my mistake. Truly sorry. (I have been using this patch for several months now and it seems like I have forgotten its history. The warning fixes are for windows. I apologize, really. > Second, I'm not thrilled about adding a lot MORE ifdefs > just to allow for debugging statements. I think we need to > find a better way to handle this part. I'll think about it > and check Yes, the ifdefs I added are ugly, I know, it was just the quick solution. Without them I get many "cast from pointer to integer of different size" warnings and the like, mostly because of pid_t type being 64 bits wide in win64. > my ISO C 1989 standard (I can't remember whether it supports > %p) when I get back to work on Tuesday. > IIRC, it should be in C89 but please verify. > Third, I really don't understand why the casts in ar.c and > arscan.c are necessary. Those members are already of type > char* (through array decay) and it's perfectly reasonable to > pass a char* to a function requiring a const char* without > any cast required. See lines 284 and 286 in arscan.c. The Mode member of the _IMAGE_ARCHIVE_MEMBER_HEADER is BYTE, ie. uunsigned char, so we have the folowing warnings: ../make-cvs/arscan.c: In function 'ar_scan': ../make-cvs/arscan.c:633: warning: pointer targets in passing argument 1 of 'sscanf' differ in signedness /opt/W64_161668/bin/../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/stdio.h:246: note: expected 'const char *' but argument is of type 'BYTE *' (... and same warnings at lines 634, 644, 645, 646, 815) > I really don't like to use casts unless absolutely necessary > (I've worked to REDUCE the total amount of casting in GNU > make source) so I'd definitely prefer to avoid these. > > Finally, it seems that some of these changes are meant to > avoid variable names conflicting with function names (open, > etc.) Is this really a warning that some compilers give? > I've never seen that warning, and it sure seems to me like > it would be almost impossible to write a portable C program > that didn't hit that warning, since every C runtime defines > a horde of functions and there is no way to know what they > all are. I don't like it. Here are the shadow warnings I get: ../make-cvs/ar.c: In function 'glob_pattern_p': ../make-cvs/ar.c:215: warning: declaration of 'open' shadows a global declaration /opt/W64_161668/bin/../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/io.h:340: warning: shadowed declaration is here ../make-cvs/job.c: In function 'create_batch_file': ../make-cvs/job.c:249: warning: declaration of 'error' shadows a global declaration ../make-cvs/make.h:373: warning: shadowed declaration is here ../make-cvs/signame.c: In function 'strsignal': ../make-cvs/signame.c:232: warning: declaration of 'signal' shadows a global declaration /opt/W64_161668/bin/../lib/gcc/x86_64-w64-mingw32/4.4.5/../../../../x86_64-w64-mingw32/include/signal.h:59: warning: shadowed declaration is here If you have any further questions, I am willing to answer to the best of my ability. Regards. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?27809> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make