Re: bcopy -> memcpy/memmove transition proposal

Re: bcopy -> memcpy/memmove transition proposal

[Kaveh R. Ghazi]

 > 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.

Re: bcopy -> memcpy/memmove transition proposal

[Per Bothner]

> 1.  Wasn't using the BSD style a GNU coding convention at some point?

In the old days, there were two main styles of Unix:  "USG" (System 5),
and "BSD".  The GNU preference was for BSD, when there was a choice.
This distinction is now completely meaningless.  Now, the default
should be Posix, unless there is a good readon not to.

> 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.

Kenner just thought it was more work than worth doing, plus a risk
of destabilizing mistakes when converting.  But if we do it so
both sets of functions can be used, the risk is reduced, since we
don't have to do an all-or-nothing conversion.  (Plus of course it
is much easier now that we use autoconf.)

> If you do "foo = memcpy()" I think you lose if
> sizeof(int)!=sizeof(ptr) and no prototype exists.

The GNU coding standards recommends against doing that, and I concur.

> The main obstacle AFAICT is that in order to use libiberty correctly,
> you have to include libiberty.h which includes ansidecl.h.

This is certainly not necessary for using the mem* functions.

The main issue I see is which approach will require less Makefile
and configure hacking.  The actual *code* for memmove etc is trivial.
Yes, it is nice to avoid duplications, but it is not that big a deal.

The situation would be simplified if the host programs (such as gen*.c)
did not require the string functions.  I see most of them define
their own - using a simple mybcopy function.  But genattr.c and
genattrtab.c use plain bcopy.  Anyone knows why the inconsistency?

If we only have to deal with the programs that run on host,
we could just link with ../libiberty/libiberty.a.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: bcopy -> memcpy/memmove transition proposal

[Jeffrey A Law]

  In message < 199809191817.LAA10496@cygnus.com >you write:
  > > If you do "foo = memcpy()" I think you lose if
  > > sizeof(int)!=sizeof(ptr) and no prototype exists.
  > 
  > The GNU coding standards recommends against doing that, and I concur.
Right, but these things do slip through once in a while and do we want
to take the chance of generating incorrect (and bloody difficult to find)
code) in such situations?

  > This is certainly not necessary for using the mem* functions.
True, but there's several files from libiberty that gcc is using
obstack, getopt, cplus-dem, pexecute, vfprintf, choose-temp, mkstemp,
and alloca.  I think Kaveh is argueing that instead of creating another
hack that we should bite the bullet and link in libiberty (dealing
with the host/build issues along the way).

jeff

Re: bcopy -> memcpy/memmove transition proposal

[Jeffrey A Law]

  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.

jeff

Re: bcopy -> memcpy/memmove transition proposal

[Kaveh R. Ghazi]

 > From: Jeffrey A Law <law@cygnus.com>
 > 
 >   In message < 199809191817.LAA10496@cygnus.com >you write:
 >   > This is certainly not necessary for using the mem* functions.
 > True, but there's several files from libiberty that gcc is using
 > obstack, getopt, cplus-dem, pexecute, vfprintf, choose-temp, mkstemp,
 > and alloca.  I think Kaveh is argueing that instead of creating another
 > hack that we should bite the bullet and link in libiberty (dealing
 > with the host/build issues along the way).
 > jeff

	Exactly.  Linking with libiberty would address allowing both
styles to be used while also making things a *lot* cleaner.  :-)

		--Kaveh

PS: The stuff Jeff listed above is the tip of the iceberg, there's lots
more cruft in the source that we should instead be getting cleanly from
libiberty.  E.g. implementations of mybcopy, mybzero, mystrerror,
mystrsignal, etc.  Stuff like vfork and xmalloc, xrealloc, etc are
implemented locally in dozens of places.  Etc, etc.  Its really a big
win to use libiberty. 

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

Re: bcopy -> memcpy/memmove transition proposal

[Kaveh R. Ghazi]

 > From: Per Bothner <bothner@cygnus.com>
 > 
 > > 1.  Wasn't using the BSD style a GNU coding convention at some point?
 > 
 > In the old days, there were two main styles of Unix:  "USG" (System 5),
 > and "BSD".  The GNU preference was for BSD, when there was a choice.
 > This distinction is now completely meaningless.  Now, the default
 > should be Posix, unless there is a good readon not to.

	So prefering the BSD style *was* mere preference and in fact
no longer relevant.  Thanks for clearing this up.

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

Re: bcopy -> memcpy/memmove transition proposal

[N8TM]

In a message dated 9/19/98 1:32:44 PM Pacific Daylight Time, jfc@mit.edu
writes:

> This means, for example, using ANSI string functions and prototypes
>  unconditionally.
I certainly have my personal doubts whether we want to test everything e.g. in
libf2c with pre-ansi compilers, and these unused historical branches make it
messy to read.  OTOH:

I just fell back on bootstrapping egcs from the HP non-ANSI compiler, and it
still works.  I had lost several days trying to repeat a bootstrap using the
expensive HP C compiler, which seems to have broken on my installation.  So I
appreciate the lowest common denominator compatibility for bootstrapping.

bcopy -> memcpy/memmove transition proposal

[Per Bothner]

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.

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:

#include <config.h>
#include "gansidecl.h"

#ifdef __STDC__
#include <stddef.h>
#else
#define size_t unsigned long
#endif

#ifndef HAVE_BCOPY
#undef bcopy
void
bcopy (src, dest, len)
  register char *src, *dest;
  int len;
{
  if (dest < src)
    while (len--)
      *dest++ = *src++;
  else
    {
      char *lasts = src + (len-1);
      char *lastd = dest + (len-1);
      while (len--)
        *(char *)lastd-- = *(char *)lasts--;
    }
}
#enidf /* !HAVE_BCOPY */

#ifdef HAVE_MEMCPY
PTR
memcpy (out, in, length)
     PTR out;
     CONST PTR in;
     size_t length;
{
    bcopy(in, out, length);
    return out;
}
#endef /* ! HAVE_MEMCPY */

#ifdef HAVE_MEMMOVE
PTR
memmove (s1, s2, n)
     PTR s1;
     CONST PTR s2;
     size_t n;
{
  bcopy (s2, s1, n);
  return s1;
}
#endif /* !HAVE_MEMMOVE */

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"?

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

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
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: bcopy -> memcpy/memmove transition proposal

[Carlo Wood]

| 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.

I fully agree.

In the past I have moved the IRC daemon (undernet) also to
ANSI functions and have had no problems.

Of course this daemon doesn't run on as many Operating Systems
as the GNU compiler, but in general it is compiled on a LOT, and
I never had any complaint.

Here is how I did it in that package:

---
1) In configure.in :

AC_HEADER_STDC
AC_CHECK_HEADERS(string.h memory.h)
AC_FUNC_MEMCMP
AC_CHECK_FUNCS(strchr memcpy memmove)

---
2) Using the following in a header file which is included before
   all other #includes in all files:

#if STDC_HEADERS
#include <string.h>
#else

#if HAVE_STRING_H
#include <string.h>
#endif

#ifndef HAVE_STRCHR
#define strchr index
#define strrchr rindex
#endif

char *strchr(), *strrchr(), *strtok();

#if HAVE_MEMORY_H
#include <memory.h>
#endif

#ifndef HAVE_MEMCPY
#define memcpy(d, s, n) bcopy ((s), (d), (n))
#define memset(a, b, c) bzero((a), (c))		/* We ONLY use memset(x, 0, y) */
#else

#if NEED_BZERO		/* This is not used yet - needs to be added to `configure' */
#define bzero(a, c) memset((a), 0, (c))		/* Some use it in FD_ZERO */
#endif

#endif /*HAVE_MEMCPY*/

#ifndef HAVE_MEMMOVE
#define memmove(d, s, n) bcopy ((s), (d), (n))
#endif

#endif /*STDC_HEADERS*/

---
3) Using in source without (compile) problems:

memcpy(...)
memcmp(...)
memmove(...)
memset(s, 0, n) <-- Only used for filling with zero's.

strchr()
strrchr()
strtok()

---
NOTES:

* I only use memset() to fill with zero's, there might be Operating Systems that
  actually still don't have memset and which uses the bzero() instead :/.
  I wouldn't know actually :)

* There are Operating Systems which use `bzero()' in a macro FD_ZERO.
  Those Operating Systems also have bzero itself defined it seems (I didn't need
  to #define NEED_BZERO yet), it should be kept in mind thought that on
  machines like that it is impossible to ONLY use the mem-family (most also
  have memset).

* I didn't run into a machine yet that didn't have strtok().
  (Some have strtoken() (not ANSI), most don't).


I hope this was helpful,

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: bcopy -> memcpy/memmove transition proposal

[Jeffrey A Law]

  In message < 199809170708.AAA23506@cygnus.com >you write:
  > 1) Do we need to add prototypes for bcopy, memmove and/or memcpy
  > to some header file, if they are "missing"?
I'd say no, but others will likely disagree :-)


  > 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.
string.c will need to be compiled twice, once for the host, once
for the build (if performing a canadian cross).  There's sample
rules in the Makefile.in to do this.

Note you may need a little sed command to change config.h to hconfig.h
when compiling it for the host (using gcc backwards gcc terminology)


jeff

Re: bcopy -> memcpy/memmove transition proposal

[John Carr]

> 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.

I will go even further.  gcc should be written in strict ANSI C and no
longer attempt to support pre-ANSI compilers.

This means, for example, using ANSI string functions and prototypes
unconditionally.

Converting the Berkeley string functions to ANSI can be done
almost automatically.

Re: bcopy -> memcpy/memmove transition proposal

[Jeffrey A Law]

  In message < 199809191507.LAA16580@contents-vnder-pressvre.mit.edu >you write:
  > > 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.
  > 
  > I will go even further.  gcc should be written in strict ANSI C and no
  > longer attempt to support pre-ANSI compilers.
I would highly recommend against this.

Some popular systems do not provide ANSI compilers by default with
their systems.  HPUX for example.  Solaris may also be in the same
boat.

Using prototypes will prevent gcc from bootstrapping with the native
compiler on such systems.

jeff

Re: bcopy -> memcpy/memmove transition proposal

[Carlo Wood]

| Some popular systems do not provide ANSI compilers by default with
| their systems.  HPUX for example.  Solaris may also be in the same
| boat.

From my ircu package ;)

  The package needs an ANSI compiler.  Some compilers need an extra option
  to compile ANSI C.  In those cases you can add these options also here.
  For example, on a HPUX-8.x you would use (if you don't have gcc):
  "cc -Aa -D_HPUX_SOURCE".

I agree that this from quite an old source, a few years ago, but I can't
believe that HPUX can afford NOT to have an ANSI compiler, so I guess
this will still work.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: bcopy -> memcpy/memmove transition proposal

[Jeffrey A Law]

  In message < 199809201419.QAA06773@jolan.ppro >you write:
  > | Some popular systems do not provide ANSI compilers by default with
  > | their systems.  HPUX for example.  Solaris may also be in the same
  > | boat.
  > 
  > >From my ircu package ;)
  > 
  >   The package needs an ANSI compiler.  Some compilers need an extra option
  >   to compile ANSI C.  In those cases you can add these options also here.
  >   For example, on a HPUX-8.x you would use (if you don't have gcc):
  >   "cc -Aa -D_HPUX_SOURCE".
  > 
  > I agree that this from quite an old source, a few years ago, but I can't
  > believe that HPUX can afford NOT to have an ANSI compiler, so I guess
  > this will still work.
hpux9, hpux10 and hpux11 do *NOT* come with an ANSI compiler.  If you
have code which uses ansi prototypes or ansi function definitions and
you have not purchased the ansi compiler you will not be able to build
that code on hpux9, hpux10, or hpux11 systesm.

I don't really remember if hpux8's compiler allowed ansi or not.  Too
long ago.

jeff

Re: bcopy -> memcpy/memmove transition proposal

[John Carr]

> Some popular systems do not provide ANSI compilers by default with
> their systems.  HPUX for example.  Solaris may also be in the same
> boat.

I know that a few systems don't have ANSI C compilers.  I even knew you
were going to mention HPUX.  I don't think that is a good enough reason to
keep gcc 10 years in the past.

HP is an exception.  Other vendors ship a modern compiler or none at all.
Solaris 2.x does not have ANY bundled C compiler but gcc is still viable on
that system.  Users without the Sun compiler can get gcc in binary form.

Re: bcopy -> memcpy/memmove transition proposal

[Jeffrey A Law]

  In message < 199809201519.LAA16184@contents-vnder-pressvre.mit.edu >you write:
  > 
  > > Some popular systems do not provide ANSI compilers by default with
  > > their systems.  HPUX for example.  Solaris may also be in the same
  > > boat.
  > 
  > I know that a few systems don't have ANSI C compilers.  I even knew you
  > were going to mention HPUX.  I don't think that is a good enough reason to
  > keep gcc 10 years in the past.
  > 
  > HP is an exception.  Other vendors ship a modern compiler or none at all.
  > Solaris 2.x does not have ANY bundled C compiler but gcc is still viable on
  > that system.  Users without the Sun compiler can get gcc in binary form.
Sorry.  These kinds of changes are not acceptable.

We must continue to support building on systems that do not come with
an ANSI compiler by default.  Sorry.

If you want to investigate schemes which allow us to use ANSI function
definitions, but also seamlessly disables such definitions when not
using an ANSI compiler that would be acceptable.

jeff