libiberty.h

libiberty.h

[Alan Modra]

This change

2005-04-11  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* libiberty.h (fopen_unlocked, fdopen_unlocked, freopen_unlocked):
	Provide prototypes for new functions.

causes

gcc -DHAVE_CONFIG_H -I. -I/src/binutils-current/opcodes -I. -D_GNU_SOURCE -I. -I/src/binutils-current/opcodes -I../bfd -I/src/binutils-current/opcodes/../include -I/src/binutils-current/opcodes/../bfd -I/src/binutils-current/opcodes/../intl -I../intl -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O -c /src/binutils-current/opcodes/m88k-dis.c -o m88k-dis.o
In file included from /src/binutils-current/opcodes/m88k-dis.c:27:
/src/binutils-current/opcodes/../include/libiberty.h:55: error: parse error before numeric constant
/src/binutils-current/opcodes/../include/libiberty.h:55: warning: function declaration isn't a prototype
/src/binutils-current/opcodes/../include/libiberty.h:56: error: parse error before numeric constant
/src/binutils-current/opcodes/../include/libiberty.h:56: warning: function declaration isn't a prototype
/src/binutils-current/opcodes/../include/libiberty.h:57: error: parse error before numeric constant
/src/binutils-current/opcodes/../include/libiberty.h:57: warning: function declaration isn't a prototype

Preprocessing shows

extern FILE *fopen_unlocked (const char *path, const char *31);
extern FILE *fdopen_unlocked (int fildes, const char *31);
extern FILE *freopen_unlocked (const char *path, const char *31, FILE *stream);

Please remove the needless parameter names.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Remove parameter names from libiberty.h

[Kaveh R. Ghazi]

As noted here:
http://sourceware.org/ml/binutils/2005-04/msg00269.html

The new f*open_unlocked function prototypes in libiberty.h are in
conflict with binutils sources because one of the parameter names
("mode") gets defined to "31" and the build dies.

Personally, I like parameter names as documentation, and I'd recommend
moving the inclusion of libiberty.h higher in opcodes/m88k-dis.c so
that "mode" isn't clobbered by the time we get these prototypes, but
it's not worth arguing over IMO.

So here's a patch to do as Alan asked.  Let me know if I should
install it.

		--Kaveh



2005-04-13  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

	* libiberty.h (fopen_unlocked, fdopen_unlocked, freopen_unlocked):
	Remove parameter names.

diff -rup orig/egcc-CVS20050413/include/libiberty.h egcc-CVS20050413/include/libiberty.h
--- orig/egcc-CVS20050413/include/libiberty.h	2005-04-13 19:33:34.502555400 -0400
+++ egcc-CVS20050413/include/libiberty.h	2005-04-13 19:34:12.465784112 -0400
@@ -52,9 +52,9 @@ extern "C" {
    the stream is setup to avoid any multi-threaded locking.  Otherwise
    return the FILE pointer unchanged.  */
 
-extern FILE *fopen_unlocked (const char *path, const char *mode);
-extern FILE *fdopen_unlocked (int fildes, const char *mode);
-extern FILE *freopen_unlocked (const char *path, const char *mode, FILE *stream);
+extern FILE *fopen_unlocked (const char *, const char *);
+extern FILE *fdopen_unlocked (int, const char *);
+extern FILE *freopen_unlocked (const char *, const char *, FILE *);
 
 /* Build an argument vector from a string.  Allocates memory using
    malloc.  Use freeargv to free the vector.  */

Re: Remove parameter names from libiberty.h

[Ian Lance Taylor]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> 2005-04-13  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
> 
> 	* libiberty.h (fopen_unlocked, fdopen_unlocked, freopen_unlocked):
> 	Remove parameter names.

Yes, please.  Thanks.

While I agree with parameter name documentation in general, I don't
think we need it for these functions, since the underlying functions
are well known.

Ian

Re: Remove parameter names from libiberty.h

[Thorsten Glaser]

Kaveh R. Ghazi dixit:

>Personally, I like parameter names as documentation, and I'd recommend

What do the GNU Coding Styles say in this regard?
If nothing, maybe we should discuss that point
a bit more lengthy and then add it?

The BSD coding styles say to NOT use parameter names
in declarations, only in the actual function, FWIW.
(It took me some time to get used to it, too.)

bye,
//mirabile

Re: Remove parameter names from libiberty.h

[DJ Delorie]

Opinions follow...

Since libiberty has a separate texinfo documentation that's supposed
to document all the parameters, and since most of libiberty's
functions are common system functions anyway, IMHO it's not as big a
deal if libiberty.h doesn't have names of parameters in it.

In DJGPP we got around this by adding underscores, but that was
acceptable only because it was the C library and that namespace was
reserved for it.

Commented out parameter names gets messy fast, esp for functions with
lots of parameters.