[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #27809] several win64 fixes
From: |
Ozkan Sezer |
Subject: |
[bug #27809] several win64 fixes |
Date: |
Sun, 04 Jul 2010 18:49:12 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061118 Fedora/3.0.11-1.fc9 Firefox/3.0.11 |
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 #27809] several win64 fixes, Ozkan Sezer, 2010/07/04
- [bug #27809] several win64 fixes, Paul D. Smith, 2010/07/04
- [bug #27809] several win64 fixes,
Ozkan Sezer <=
- [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/05
- [bug #27809] several win64 fixes, Paul D. Smith, 2010/07/05
- Re: [bug #27809] several win64 fixes, Eli Zaretskii, 2010/07/05
- Re: [bug #27809] several win64 fixes, Eli Zaretskii, 2010/07/09
- Re: [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/09
- Re: [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/09
- Re: [bug #27809] several win64 fixes, Eli Zaretskii, 2010/07/09
- Re: [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/09
- Re: [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/09
- [bug #27809] several win64 fixes, Ozkan Sezer, 2010/07/05