bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-inetutils] [sr #104441] inetuils 1.4.2 on sparc


From: Alfred M. Szmidt
Subject: [bug-inetutils] [sr #104441] inetuils 1.4.2 on sparc
Date: Fri, 29 Jun 2007 19:45:24 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070602 Ubuntu/deltad-security Firefox/1.5.0.12

Follow-up Comment #5, sr #104441 (project inetutils):

This is great news, now we know why things blow up.  But making inetutils use
its own version of memcpy is a really bad idea, so we can't do that.  What can
be done is something else, that might fix these problems on Sparc, namley, use
the memcpy from gnulib.

Could you try using the following version of memcpy on your system, and see
if it works?

void *
memcpy (void *destaddr, void const *srcaddr, size_t len)
{
  char *dest = destaddr;
  char const *src = srcaddr;

  while (len-- > 0)
    *dest++ = *src++;
  return destaddr;
}

This version of memcpy isn't as optimised as the glibc one, but it works on
all C systems, and it is distributed with gnulib. To use it, just plug it in
like you did with the glibc one.


Now it would be most interesting to find out what exactly goes wrong.

I see that on SPARC (see [libc]/sysdeps/sparc/sparc32/memcopy.h) reg_char
gets redefined to a `int', while on other platforms it is a `char'.  The same
would be true for your patch, i.e. reg_char is `char'.  Could you try defining
reg_char as a `int' and see what happens?  I think this is the only part that
can cause any change to the glibc memcpy.

This version of memcpy isn't as optimised as the glibc one, but it works on
all C systems, and it is distributed with gnulib. To use it, just plug it in
like you did with the glibc one.


Now it would be most interesting to find out what exactly goes wrong.  I see
that on SPARC (see [libc]/sysdeps/sparc/sparc32/memcopy.h) reg_char gets
redefined to a `int', while on other platforms it is a `char'.  The same
would be true for your patch, i.e. reg_char is a `char'.  Could you try
defining reg_char as a `int' and see what happens?  I think this is the only
part that can cause any change to the glibc memcpy.

This version of memcpy isn't as optimised as the glibc one, but it works on
all C systems, and it is distributed with gnulib. To use it, just plug it in
like you did with the glibc one.


Now it would be most interesting to find out what exactly goes wrong.  I see
that on SPARC (see [libc]/sysdeps/sparc/sparc32/memcopy.h) reg_char gets
redefined to a `int', while on other platforms it is a `char'.  The same
would be true for your patch, i.e. reg_char is a `char'.  Could you try
defining reg_char as a `int' and see what happens?  I think this is the only
part that can cause any change to the glibc memcpy.

Annother thing that might cause this is endianess, but I doubt that.  What
kind of SPARC is this?

Thank you for the lovley bug report!

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?104441>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]