[rfa] `struct _bfd' -> `struct bfd'

[rfa] `struct _bfd' -> `struct bfd'

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

Hello,

The attached renames the BFD object to `struct bfd' from `struct _bfd'. 
  To ensure backward compatibility with existing code it also #defines 
_bfd -> bfd.

Having `struct bfd' available will, I think, legitimize its use as an 
opaque declaration vis:

	struct bfd;
	void func (struct bfd *abfd);

Also, as far as I know, symbols with a leading `_' live in the system 
name space.

Ok to commit?
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1671 bytes --]

2003-02-24  Andrew Cagney  <cagney@redhat.com>

	* bfd.c (struct bfd): Rename "struct _bfd".
	* bfd-in.h: Update copyright.
	(struct bfd): Rename "struct _bfd".
	(_bfd): Define for backward compatibility.
	* bfd-in2.h: Regenerate.

Index: bfd-in.h
===================================================================
RCS file: /cvs/src/src/bfd/bfd-in.h,v
retrieving revision 1.55
diff -u -r1.55 bfd-in.h
--- bfd-in.h	8 Dec 2002 03:34:38 -0000	1.55
+++ bfd-in.h	24 Feb 2003 06:34:52 -0000
@@ -1,7 +1,8 @@
 /* Main header file for the bfd library -- portable access to object files.
-   Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-   2000, 2001, 2002
-   Free Software Foundation, Inc.
+
+   Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+   1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+
    Contributed by Cygnus Support.
 
    This file is part of BFD, the Binary File Descriptor library.
@@ -68,7 +69,10 @@
 #endif
 
 /* Forward declaration.  */
-typedef struct _bfd bfd;
+typedef struct bfd bfd;
+/* For backward compatibility.  Keep code that was using "struct
+   _bfd" working.  */
+#define _bfd bfd
 
 /* Boolean type used in bfd.  Too many systems define their own
    versions of "boolean" for us to safely typedef a "boolean" of
Index: bfd.c
===================================================================
RCS file: /cvs/src/src/bfd/bfd.c,v
retrieving revision 1.46
diff -u -r1.46 bfd.c
--- bfd.c	14 Feb 2003 11:16:09 -0000	1.46
+++ bfd.c	24 Feb 2003 06:35:21 -0000
@@ -34,7 +34,7 @@
 
 CODE_FRAGMENT
 .
-.struct _bfd
+.struct bfd
 .{
 .  {* A unique identifier of the BFD  *}
 .  unsigned int id;

Re: [rfa] `struct _bfd' -> `struct bfd'

[Andrew Cagney]

To follow this up, I've a stylistic question.  Which of:

	sec_ptr
	asection *
	struct sec *

is prefered.  GDB uses all three which makes things really confusing. 
While GDB's coding standards prefer `struct sec *' (and detest sec_ptr) 
does BFD have a stylistic preference.

Andrew

Re: [rfa] `struct _bfd' -> `struct bfd'

[Ian Lance Taylor]

Andrew Cagney <ac131313@redhat.com> writes:

> To follow this up, I've a stylistic question.  Which of:
> 
> 	sec_ptr
> 	asection *
> 	struct sec *
> 
> is prefered.  GDB uses all three which makes things really
> confusing. While GDB's coding standards prefer `struct sec *' (and
> detest sec_ptr) does BFD have a stylistic preference.

I certainly think sec_ptr should be removed.

I tended to use asection * myself.  But then I tended to use bfd *,
not struct _bfd *.

Ian

Re: [rfa] `struct _bfd' -> `struct bfd'

[Hans-Peter Nilsson]

On Mon, 24 Feb 2003, Andrew Cagney wrote:

> The attached renames the BFD object to `struct bfd' from `struct _bfd'.
>   To ensure backward compatibility with existing code it also #defines
> _bfd -> bfd.

Would this break using bfd from C++?
Or building with pre-ISOC89 compilers?  (Ouch!  Don't hit me! ;-)

> Having `struct bfd' available will, I think, legitimize its use as an
> opaque declaration vis:
>
> 	struct bfd;
> 	void func (struct bfd *abfd);

And "bfd *" does not fit that purpose?

> Also, as far as I know, symbols with a leading `_' live in the system
> name space.

No, it's _ followed by upper-case letter, e.g "_Z".

brgds, H-P

Re: [rfa] `struct _bfd' -> `struct bfd'

[Andreas Schwab]

Hans-Peter Nilsson <hp@bitrange.com> writes:

|> On Mon, 24 Feb 2003, Andrew Cagney wrote:
|> 
|> > Having `struct bfd' available will, I think, legitimize its use as an
|> > opaque declaration vis:
|> >
|> > 	struct bfd;
|> > 	void func (struct bfd *abfd);
|> 
|> And "bfd *" does not fit that purpose?

That would require that bfd be a complete type, since you can only forward
declare struct and union types.

|> 
|> > Also, as far as I know, symbols with a leading `_' live in the system
|> > name space.
|> 
|> No, it's _ followed by upper-case letter, e.g "_Z".

At file scope all identifiers starting with `_' are reserved, including
struct tags.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [rfa] `struct _bfd' -> `struct bfd'

[Alan Modra]

On Mon, Feb 24, 2003 at 01:48:45AM -0500, Andrew Cagney wrote:
> 	(_bfd): Define for backward compatibility.

Do we really need this?  Seems like you can update gdb and sim in
tandem with the rest of your change.  Other users of bfd will just
need a small and fairly obvious change if they happen to use
struct _bfd, _and_ want to use a new libbfd.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [rfa] `struct _bfd' -> `struct bfd'

[Andrew Cagney]

> On Mon, Feb 24, 2003 at 01:48:45AM -0500, Andrew Cagney wrote:
> 
>> 	(_bfd): Define for backward compatibility.
> 
> 
> Do we really need this?  Seems like you can update gdb and sim in
> tandem with the rest of your change.  Other users of bfd will just
> need a small and fairly obvious change if they happen to use
> struct _bfd, _and_ want to use a new libbfd.

Well, for a day or so.   It will make the switch easier.

Andrew

Re: [rfa] `struct _bfd' -> `struct bfd'

[Alan Modra]

On Wed, Feb 26, 2003 at 09:14:21PM -0500, Andrew Cagney wrote:
> >On Mon, Feb 24, 2003 at 01:48:45AM -0500, Andrew Cagney wrote:
> >
> >>	(_bfd): Define for backward compatibility.
> >
> >
> >Do we really need this?  Seems like you can update gdb and sim in
> >tandem with the rest of your change.  Other users of bfd will just
> >need a small and fairly obvious change if they happen to use
> >struct _bfd, _and_ want to use a new libbfd.
> 
> Well, for a day or so.   It will make the switch easier.

OK, go ahead.  I'll delete it tomorrow. :-)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [rfa] `struct _bfd' -> `struct bfd'

[Alan Modra]

On Thu, Feb 27, 2003 at 12:48:48PM +1030, Alan Modra wrote:
> On Wed, Feb 26, 2003 at 09:14:21PM -0500, Andrew Cagney wrote:
> > >Do we really need this?  Seems like you can update gdb and sim in
> > 
> > Well, for a day or so.   It will make the switch easier.
> 
> OK, go ahead.  I'll delete it tomorrow. :-)

	* bfd-in.h (_bfd): Don't define.
	* bfd.c: Rename occurrences of "struct _bfd" to "struct bfd".
	* syms.c: Likewise.
	* bfd-in2.h: Regenerate.

Index: bfd/bfd-in.h
===================================================================
RCS file: /cvs/src/src/bfd/bfd-in.h,v
retrieving revision 1.56
diff -u -p -r1.56 bfd-in.h
--- bfd/bfd-in.h	27 Feb 2003 21:24:36 -0000	1.56
+++ bfd/bfd-in.h	28 Feb 2003 07:14:20 -0000
@@ -70,9 +70,6 @@ extern "C" {
 
 /* Forward declaration.  */
 typedef struct bfd bfd;
-/* For backward compatibility.  Keep code that was using "struct
-   _bfd" working.  */
-#define _bfd bfd
 
 /* Boolean type used in bfd.  Too many systems define their own
    versions of "boolean" for us to safely typedef a "boolean" of
Index: bfd/bfd.c
===================================================================
RCS file: /cvs/src/src/bfd/bfd.c,v
retrieving revision 1.47
diff -u -p -r1.47 bfd.c
--- bfd/bfd.c	27 Feb 2003 21:24:36 -0000	1.47
+++ bfd/bfd.c	28 Feb 2003 07:14:23 -0000
@@ -65,7 +65,7 @@ CODE_FRAGMENT
 .
 .  {* The caching routines use these to maintain a
 .     least-recently-used list of BFDs.  *}
-.  struct _bfd *lru_prev, *lru_next;
+.  struct bfd *lru_prev, *lru_next;
 .
 .  {* When a file is closed by the caching routines, BFD retains
 .     state information on the file here...  *}
@@ -139,13 +139,13 @@ CODE_FRAGMENT
 .
 .  {* Stuff only useful for archives.  *}
 .  PTR arelt_data;
-.  struct _bfd *my_archive;     {* The containing archive BFD.  *}
-.  struct _bfd *next;           {* The next BFD in the archive.  *}
-.  struct _bfd *archive_head;   {* The first BFD in the archive.  *}
+.  struct bfd *my_archive;      {* The containing archive BFD.  *}
+.  struct bfd *next;            {* The next BFD in the archive.  *}
+.  struct bfd *archive_head;    {* The first BFD in the archive.  *}
 .  bfd_boolean has_armap;
 .
 .  {* A chain of BFD structures involved in a link.  *}
-.  struct _bfd *link_next;
+.  struct bfd *link_next;
 .
 .  {* A field used by _bfd_generic_link_add_archive_symbols.  This will
 .     be used only for archive elements.  *}
Index: bfd/syms.c
===================================================================
RCS file: /cvs/src/src/bfd/syms.c,v
retrieving revision 1.28
diff -u -p -r1.28 syms.c
--- bfd/syms.c	14 Feb 2003 09:31:57 -0000	1.28
+++ bfd/syms.c	28 Feb 2003 07:14:35 -0000
@@ -192,7 +192,7 @@ CODE_FRAGMENT
 .     instead, except that some symbols point to the global sections
 .     bfd_{abs,com,und}_section.  This could be fixed by making
 .     these globals be per-bfd (or per-target-flavor).  FIXME.  *}
-.  struct _bfd *the_bfd; {* Use bfd_asymbol_bfd(sym) to access this field.  *}
+.  struct bfd *the_bfd; {* Use bfd_asymbol_bfd(sym) to access this field.  *}
 .
 .  {* The text of the symbol. The name is left alone, and not copied; the
 .     application may not alter it.  *}


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: [rfa] `struct _bfd' -> `struct bfd'

[Andrew Cagney]

PS, Perhaps they should (mostly) go in src/cpu/<cpu>/frv.*?

Andrew

Re: [rfa] `struct _bfd' -> `struct bfd'

[Doug Evans]

Andrew Cagney writes:
 > PS, Perhaps they should (mostly) go in src/cpu/<cpu>/frv.*?

Or (for completeness' sake), src/cpu/cgen/*.

Or ...
GCC didn't use to have config/<cpu> subdirs.
They were added when config got too big.
I think it would be reasonable to just use src/cpu/frv.*
(and ditto for the other .cpu/.opc files)
until the directory became populated enough that which form
the next step took became more clear.

But in the end I have no strong opinion.

P.S. I still think .opc files should go in src/opcodes, but no matter.

Re: [rfa] `struct _bfd' -> `struct bfd'

[Andrew Cagney]

> Andrew Cagney writes:
>  > PS, Perhaps they should (mostly) go in src/cpu/<cpu>/frv.*?
> 
> Or (for completeness' sake), src/cpu/cgen/*.
> 
> Or ...
> GCC didn't use to have config/<cpu> subdirs.
> They were added when config got too big.
> I think it would be reasonable to just use src/cpu/frv.*
> (and ditto for the other .cpu/.opc files)
> until the directory became populated enough that which form
> the next step took became more clear.

True.   That may be sooner than you think.  For MIPS, there is the 
potential for: mips.igen, tx.igen, vr.igen, mdmx.igen, m16.igen, 
sb1.igen, ....

Andrew