Re: bfd_read and bfd_write

[Alan Modra <amodra@bigpond.net.au>]

On Wed, Sep 05, 2001 at 08:26:26PM -0400, Andrew Cagney wrote:
> > On Wed, Sep 05, 2001 at 12:45:10PM -0400, Andrew Cagney wrote:
> > 
> >> rather than change the function signature, why not introduce a new 
> >> interface and then deprecate the old one?
> > 
> > 
> > Because then you'll never get rid of the old interface.
> why not introduce the new _external_ interface, go around eliminating 
> all known uses of the old.  once done (new release made?) zap the old 
> interface.  a common pratice is to add code to the old interface to 
> issue a warning the first time it is called.
> 
> alan's basic problem of needing to co-ordinate everything so it can all 
> happen at once just goes away.

I have patches for all of bfd, gas, gdb.  Shouldn't be more than half an
hour checking them all in, unless my net connection breaks or something.
I tend to agree with rth that it's better to break things temporarily
and force use of a new interface than leave compatibility code around,
unless it's a major effort to change over.

Of course, you could force me to leave the old code in by witholding
permission to make the changes to gdb.  :-)

> it also covers the k&r problem - you cant rely on a k&r compiler to 
> report parameter mismatches.

That's the other part of my bfd patchset:  Fixing all the -Wconversion
errors that gcc reports.  I've done 32 bit native, 32 -> 64 bit xcompiles,
with 64 bit native and 64 -> 32 bit xcompiles yet to do.  The last two
cases should catch all the int/long mismatches, the first two catch
int/long vs. bfd_vma/bfd_size_type etc. mismatches.

Alan