[BUG] memccpy treats size_t as int

Howland Craig D (Craig) howland@LGSInnovations.com
Wed Sep 22 11:27:00 GMT 2010


The exact same problem is also in memcpy.c, mempcpy.c, and memmove.c
(same
problem, a name different).  I did not carefully look at all of the
files in string, but did scan them and found no other instances of
size_t to int.
 
I don't see why len is ever created, actually.  In the short form
of the functions, the len0 parameter is used in the code.  In the
longer forms len is created from len0, but len0 is never used again.
(In memmove.c, the problem is the same with one name change:  len0 is
length.)
 
Assuming that there is not a special reason for this, the attached
patch corrects the 4 files.  (I left the slightly different name in
memmove.c to minimize the changes, although it was tempting to change
the name to make the similarities between the files even more obvious.)

Craig 

ChangeLog entry:
2010-09-21  Craig Howland <howland@LGSInnovations.com>

	* libc/string/memcpy.c: Do not assign size_t parameter to int
(use
	parameter directly, instead).
	* libc/string/memccpy.c:  Likewise.
	* libc/string/mempcpy.c:  Likewise.
	* libc/string/memmove.c:  Likewise.

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of David A. Ramos
Sent: Tuesday, September 21, 2010 4:52 PM
To: newlib@sourceware.org
Subject: [BUG] memccpy treats size_t as int

Hi newlib maintainers,

It's come to my attention that newlib's memccpy (libc/string/memccpy.c)
casts the len0 argument from size_t (as required by the SUS) to int. On
64-bit Linux environments, this erroneously drops the high 32 bits. I'm
not familiar enough with newlib to know whether this issue is isolated
to memccpy or whether it's standard practice in the project. Just
thought I'd report it!

More specifically:
  int   len =  len0;
should be:
  size_t len =  len0;

-David


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: memcpy.patch.txt
URL: <http://sourceware.org/pipermail/newlib/attachments/20100922/9ea88992/attachment.txt>


More information about the Newlib mailing list