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: patches for Irix binutils 2.18 -- removal of some casts


 > Alan
 > diff -u -p -r1.105 tc-m68k.c
 > --- ./gas/config/tc-m68k.c 20 Oct 2008 01:03:50 -0000 1.105
 > +++ ./gas/config/tc-m68k.c 21 Oct 2008 00:01:39 -0000
 > @@ -4422,7 +4422,7 @@ md_begin (void)
 >    obstack_begin (&robyn, 4000);
 >    for (i = 0; i < m68k_numopcodes; i++)
 >      {
 > -      hack = slak = (struct m68k_incant *) obstack_alloc (&robyn, sizeof (struct m68k_incant));
 > +      hack = slak = obstack_alloc (&robyn, sizeof (struct m68k_incant));
 >        do
 > {
 >   ins = m68k_sorted_opcodes[i];


This is hypocritical of me, I realize, and maybe annoying:


Do you care about making or leaving the code C++ compatible?
Some of your change removes C++ compat.
My change -- both of my renditions of it and your rendition -- are too lazy to be C++ compat.
void* was expedient for me at the time but I'm willing to go through the tedium to "fix" them.
(maybe even to get the "whole thing" to be valid C++)
I realize that C++-incompat can be a feature -- a deliberate barrier to something that is perhaps not desirable.


I know gcc has gone through and fixed C++-compat, stuff like:
 s/this/self/
 s/class/clas/
 s/string/str/ (questionable)
 s/char foo[3]="foo"/char foo[]="foo"/
 s/const/extern const/ (not sure folks do this, but I like it -- it makes the code have the same meaning in either language, even if it was legal in either already)
 ifdef __cplusplus extern "C" around every source file (again not sure folks do this, but I like it; avoid the unwieldly mangled names...)
 etc.


not sure if there's any similar rumblings in binutils.


 - Jay


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