autconf bcopy and bzero

autconf bcopy and bzero

[Dan Nicolaescu]

uclibc uses #define to define bcopy and bzero in <strings.h>
emacs' configure script decides that bcopy and bzero are not available
and then #defines them in config.h. 

Then all the files get warnings like this:

In file included from frame.c:22:
./config.h:1159:1: warning: "bcopy" redefined
In file included from ./config.h:1096,
                 from frame.c:22:
/usr/include/string.h:329:1: warning: this is the location of the
previous definition
In file included from frame.c:22:
./config.h:1162:1: warning: "bzero" redefined
In file included from ./config.h:1096,
                 from frame.c:22:
/usr/include/string.h:330:1: warning: this is the location of the
previous definition

Can somebody that understands the autoconf magic involved please fix
this? Thanks.

Re: autconf bcopy and bzero

[Tom Tromey]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> uclibc uses #define to define bcopy and bzero in <strings.h>
Dan> emacs' configure script decides that bcopy and bzero are not available
Dan> and then #defines them in config.h. 

Can you look in your config.log to see why the existing bcopy test
failed?  I think it should work ok.

Dan> In file included from frame.c:22:
Dan> ./config.h:1159:1: warning: "bcopy" redefined
Dan> In file included from ./config.h:1096,
Dan>                  from frame.c:22:
Dan> /usr/include/string.h:329:1: warning: this is the location of the
Dan> previous definition

One way to get rid of the warning is to '#undef bcopy' before defining
it.  Alternatively, the code could read:

    #if !defined HAVE_BCOPY && !defined bcopy
    #define bcopy(a,b,s) memcpy (b,a,s)
    #endif

Tom

Re: autoconf bcopy and bzero

[Tom Tromey]

>> One way to get rid of the warning is to '#undef bcopy' before defining
>> it.  Alternatively, the code could read:
>> 
>> #if !defined HAVE_BCOPY && !defined bcopy
>> #define bcopy(a,b,s) memcpy (b,a,s)
>> #endif

Dan> That's the obvious think to do, but is it correct?

I don't think there is a really correct answer.  IMO these can't hurt,
and they should always give a working result.  For things I maintain,
that would be good enough; I don't know what the Emacs approach is
here.

Using bcopy et al is a bit funny.  Most other projects I follow moved
to the mem* functions years ago.  This is very minor, though, I
suppose.

Tom

Re: autoconf bcopy and bzero

[Dan Nicolaescu]

Tom Tromey <tromey@redhat.com> writes:

  > >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > Dan> uclibc uses #define to define bcopy and bzero in <strings.h>
  > Dan> emacs' configure script decides that bcopy and bzero are not available
  > Dan> and then #defines them in config.h. 
  > 
  > Can you look in your config.log to see why the existing bcopy test
  > failed?  I think it should work ok.

The autoconf test does not include <strings.h>, so it can't see
definitions for bzero/bcopy. 

config.h does include <strings.h>


  > Dan> In file included from frame.c:22:
  > Dan> ./config.h:1159:1: warning: "bcopy" redefined
  > Dan> In file included from ./config.h:1096,
  > Dan>                  from frame.c:22:
  > Dan> /usr/include/string.h:329:1: warning: this is the location of the
  > Dan> previous definition
  > 
  > One way to get rid of the warning is to '#undef bcopy' before defining
  > it.  Alternatively, the code could read:
  > 
  >     #if !defined HAVE_BCOPY && !defined bcopy
  >     #define bcopy(a,b,s) memcpy (b,a,s)
  >     #endif

That's the obvious think to do, but is it correct?