bcopy -> memcpy/memmove transition proposal

Jeffrey A Law law@cygnus.com
Sun Sep 20 06:39:00 GMT 1998

  In message < 199809191524.LAA06097@caip.rutgers.edu >you write:
  > 	While this issue alone doesn't particularly bother me, I am
  > frustrated by the libiberty situation in general.  The main obstacle
  > AFAICT is that in order to use libiberty correctly, you have to
  > include libiberty.h which includes ansidecl.h.  The ansidecl.h from
  > libiberty conflicts with gansidecl.h from gcc.  E.g. ansidecl.h
  > defines PROTO as an obsolete macro to mean something other than what
  > gansidecl.h does.  One is encouraged to use PARAMS instead.
OK.  So going this direction (PARAMS instead of PROTO) is another
step towards making gcc conform to the rest of the GNU world.  Good.

  > event that the function is *not* missing.  But this decision may have
  > been made before common use of the autoconf macro GCC_NEED_DECLARATION
  > which makes this problem go away.
Quite likely.  libiberty was only recently converted to autoconf.

  > 1.  Resolve conflicts between gansidecl.h and ansidecl.h in gcc's source
  > code.  I.e. s/PROTO/PARAMS/, etc.  (I believe we should follow the
  > libiberty convention, although this requires lots of busy work changes
  > in gcc's source.  It *would* be a good time to resolve all the
  > formatting differences though.  E.g.  "PROTO((" vs "PROTO ((".)
Agreed.  Luckily this stuff is generally not found in the meat of the
source files (which would bring the merge issues into play).

[ ... ]

  > I don't think it all has to be done at once.  We could do it in stages. 
Basically sounds good.  And as you say, we can take small steps
instead of trying to do everything at once.

One might consider moving the PROTO conversion later in the process.
That way we'd know that we have a workable solution before we go change
almost every C source file in the distribution.


More information about the Gcc mailing list