[bug #27809] several win64 fixes

[Ozkan Sezer]

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/