Re: bcopy -> memcpy/memmove transition proposal

["Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>]

 > From: Per Bothner <bothner@cygnus.com>
 > 
 > It is really ridiculous that gcc still uses the non-ANSI functions
 > (such as bcopy), rather than the standard ANSI functions.  We all
 > (I hope) agree this is bogus, but fixing them all is a hassle.
 > Here is a concrete suggestion for how we can deal with a mix
 > of both styles, and fix them as convenient.


Per,

	I have a couple of comments/questions.

1.  Wasn't using the BSD style a GNU coding convention at some point?
I don't care really, but if it did exist I wanted to know why before
we chuck it.  I also want to make sure if we violate the coding
standards, we do so consciously/intentionally rather than by oversight.

	Was the BSD style merely preference on RMS' part?  Did this
convention go away?  I briefly scanned a recent copy of the standards
and couldn't find it.  But I also can't shake the recollection that
its true.  In fact, I recall something on gcc2 within the last 1-1.5
years where someone asked kenner if it was time to switch and he
rejected it for some reason.




 > 
 > 1) Add memcpy, memmove, memzero, strchr, and strrchr to
 > the list of functions in the AC_CHECK_FUNCS macro in configure.in.
 > 
 > 2) Add a new file string.c, which is always linked in.
 > This would look something like:
 > 


	Your proposal looks like you are reimplementing parts of
libiberty inside gcc.  Why not just go all the way and use libiberty?
There are serious issues involved, but I would suggest biting the
bullet and doing it completely.  More on that below.




 > 
 > There are some issues I'm not sure about:
 > 
 > 1) Do we need to add prototypes for bcopy, memmove and/or memcpy
 > to some header file, if they are "missing"?


	Already done for the b* style ones in system.h.  If we go with
your approach, we might as well prototype the mem* ones too.


 > 
 > I don't see any necessity, or reason why it would be desirable,
 > but may be missing something.


	If you do "foo = memcpy()" I think you lose if
sizeof(int)!=sizeof(ptr) and no prototype exists.  There may be other
reasons.  I see no reason why not to do this given that the support
and infrastructure for doing so already exists.



 > 
 > 2) Is there a problem with build vs host?  Is is the difference
 > between auto-host.h and auto-config.h?  I'm not clear on how
 > this happens;  perhaps we may need to compile string.c twice,
 > once for build and once for host.
 > 
 > Comments?  This suituation has been bugging for a long time, and
 > I think it is time to fix it.
 > 	--Per Bothner


	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.

	Also, it seems that libiberty.h only prototypes original
functions it provides, not replacements for missing ones.  I think
this may have been done to avoid conflicts with system headers in the
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.

	I know the scope is vastly larger, but we've done a lot of
hacks to avoid undertaking libiberty, your proposal being the latest
in a long series.  (I'm way guilty of this too.)  Recalling those and
the fact that they are growing is what bugs me the most.  So I'd like
to seriously consider libiberty now.  I'll outline the steps as I see
them and I'd like to get comments.

	Libiberty conversion steps:

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 ((".)

2.  Move any extra stuff from gansidecl.h to ansidecl.h.

3.  Nuke the gansidecl.h file and all references to including it.

4.  Have *config.h in gcc include ansidecl.h from libiberty.

5.  (Have system.h include libiberty.h?)  Add missing prototypes for
remaining system functions provided by libiberty based on whether
GCC_NEED_DECLARATION indicates we should.  Stop defining the b*
functions in terms of the mem* ones in system.h.  (No longer needed.)

6.  Setup Makefiles to build two copies of libiberty, "host" and
"build", and link appropriately with executables.

7.  Nuke stuff in gcc's source locally that's now provided by
libiberty.  E.g. local xmalloc definitions, prototypes, etc.

8.  Cross our fingers. :-)

I don't think it all has to be done at once.  We could do it in stages. 

	I'd welcome any comments.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Icon CMT Corp.