Re: Got dropped...

Ed Beroset wrote:
> > - Saner backends, at least the ELF output is full of bugs.  Can we use 
> > libbfd?
>
> I would argue for cleaned up inter-module interface first and THEN saner 
> backends.  My big pet peeve is the preprocessor's interface to the rest 
> of the system, so I'll volunteer to take that on.

Tag, you're it.

libbfd would pretty much means outsourcing the backend work if we can 
use the libbfd backend interface.  That'd be a huge win, since the 
libbfd backends have a huge amount of work associated with them, and 
support a massive variety of formats.

One option, of course, is to have a bfd backend on our own simpler 
interface; might be necessary for the bin format in particular.

> > - 64-bit support.  x86-64 has gained huge momentum.  This means new 
> > backends!
> > - On the note above, actually use portable types; use <inttypes.h> and 
> > provide substitutes for those that don't have it, if those compilers 
> > still matter.
>
> I think we should handle those by exception -- move first and address 
> complaints if they turn up.  Time marches on...

Actually, I have written <inttypes.h> for a number of platforms.  We 
really only need two or three versions.  Let's use it.  We currently 
have places where we use "unsigned long" to mean "uint32_t", which 
results in ndisasm producing wrong output on 64-bit machines.

It might also be worth using a metatype to mark x86 addresses.

> I think we should also clean up the code we've got.  I mentioned splint 
> before; I'll go ahead and add just three lines to Makefile.in to allow 
> one to do "make splint" (but I'm open to alternative names) and get a 
> diagnostic dump of what that tool thinks is awry.

Of course.

        -hpa


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/