This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Patch for bfd/cache.c - explicit cast to void*


I use 3 compilers in Interix: May seems strange but that's how it is.
Interix gcc, currently only available as x86
cc and icc ksh script for 64bit MS and Intel compiler.

$ cc -V
15.00.30729.01
$ icc -V
11.0
$ gcc -v
Target: i586-pc-interix3
Thread model: posix
gcc version 4.2.0
$ uname -a
Interix max2008 6.0 10.0.6030.0 genuineintel Intel64_Family_6_Model_26_Stepping_4

With my recent Interix x86_64 target patch (reviewed) applied to a fresh GNU binutils release 2.19.1, it compiles out-of-the-box except for this issue with cc.

It's no big deal to change this yourself if needed, I just thought it would be nice to get it clean. I can't see why anyone would object, the void* cast must be done in any case I think. An explicit cast would remove any doubt by the compiler on what to do. I assume this is a late restriction applied to the MS compiler (VS2008 SP1).


thanks
Jerker


> -----Original Message-----
> From: Dave Korn [mailto:dave.korn.cygwin@googlemail.com]
> Sent: Monday, March 02, 2009 1:06 AM
> To: tromey@redhat.com
> Cc: Jerker BÃck; binutils@sourceware.org
> Subject: Re: Patch for bfd/cache.c - explicit cast to void*
> 
> Tom Tromey wrote:
> >>>>>> "Jerker" == Jerker BÃck <jerker.back@telia.com> writes:
> 
>   For some reason I'm not seeing a lot of Jerker's posts.  Pardon me for
> piggy-backing on your reply, Tom, most of this is addressed to Jerker.
> 
> > Jerker> Some compilers refuse to compile the current source and emmits:
> > Jerker> error C2036: 'void *' : unknown size
> 
>   Errr... where is there any void* pointer arithmetic going on in the
> original?  Does MSVC have addition and casts in the wrong precedence?
> 
> > gdb uses -Wpointer-arith when compiled with gcc; perhaps binutils
> > ought to do this as well.
> >
> > Jerker> +      chunk_nread = cache_bread_1 (abfd, (void*)((file_ptr)buf
> + nread), chunk_size);
> >
> > I think just (char *) buf + nread would be more typical.
> 
>   That's how the code already reads currently:
> 
> > -chunk_nread = cache_bread_1(abfd, (char*)buf + nread, chunk_size);
> > +chunk_nread = cache_bread_1(abfd, (void*)((file_ptr)buf + nread),
> >    chunk_size);
> 
>   And I couldn't get the current code to warn under MSVC6.1 with this
> testcase:
> 
> --------------------------------------------------------------------------
> typedef unsigned long int file_ptr;
> 
> static file_ptr
> cache_bread_1 (/*struct bfd *abfd, */void *buf, file_ptr nbytes)
> {
>   return 0;
> }
> 
> int test (void *buf, file_ptr nread, file_ptr chunk_size)
> {
>   file_ptr chunk_nread;
>   chunk_nread = cache_bread_1 (/*abfd, */(char *) buf + nread,
> chunk_size);
>   return (chunk_nread & 0xffff);
> }
> 
> int main (int argc, const char **argv)
> {
>   char buf[20];
>   return test (&buf[0], 123, 456);
> }
> --------------------------------------------------------------------------
> 
> when compiled in either C or C++.
> 
>   Jerker, could you confirm that you were definitely using clean sources
> when
> you saw this problem originally?  And give somehow steps to reproduce this
> problem, or details of the environment you're seeing it in?
> 
>     cheers,
>       DaveK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]