bitwise with memcpy and void*

bitwise with memcpy and void*

[Robert Catherall]

Hello,

I'm interested in detecting endian mismatches in C code. The bitwise
facility in sparse seems ideal, however I ran into an interesting
example yesterday which sparse did not detect. I'm using sparse-0.4.1.

1. Specifically data was copied from a buffer in BE format to a buffer
in LE format using memcpy(). Using memcpy is kind of implying that the
programmer believes the types of the source and destination buffers are
compatible, so it would be nice if sparse could issue a warning when
they are not.

Here is a trivial test case.

#include "something-to-give-me-bitwise-types.h"

extern __le32* pLEdata;
extern __be32* pBEdata;

void copyBuffer(size_t length) {
	memcpy(pLEdata,pBEdata,length);
}

I would like to get a warning on line 7 (memcpy) because the types of
src and dst are different. 
I've tried #define memcpy(d,s,l) (*(d)=*(s)) which seems to work but
feels a bit ugly.

Is there a better way to do this?

2. Next I tried writing my own memcpy in the hope that I would then get
warnings in the normal way but got a warning implying that sparse knows
about memcpy 

warning: conflicting types for built-in function "memcpy"
foo.c: In function "memcpy":

3. So finally I tried writing a replacement my_memcpy whereupon I
discovered that apparently assigning a bitwise pointer to a void pointer
eliminates the bitwise-ness i.e. (append to the previous test case)

static void my_memcpy(void* dst, void* src, size_t len) {
 char* d = (char*)dst;
 char* s = (char*)src;

 while( len-- > 0 ) *(d++) = *(s++);
}

void copyBuffer_2(size_t length) {
 my_memcpy(pLEdata, pBEdata, length);
}

results in no warnings about passing a __le32* or __be32* to
my_memcpy(). You do get warnings if, for example, dst is an int*. I
suppose I can see that because you can't dereference a void* it doesn't
matter what it's pointing to, but on the other hand it's quite common to
throw void* around and cast it to what you actually want later on. Not
good practice, but all the more reason for sparse to complain :-)

Is this treatment of void* expected behaviour?

I'm new to sparse, and I apologise if these turn out to be dumb
questions. I did read the various bits of documentation and searched
this list first.

Thanks
Robert
-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Re: bitwise with memcpy and void*

[Christopher Li]

On Sat, Jul 11, 2009 at 9:47 AM, Robert
Catherall<Robert.Catherall@arm.com> wrote:
> 1. Specifically data was copied from a buffer in BE format to a buffer
> in LE format using memcpy(). Using memcpy is kind of implying that the
> programmer believes the types of the source and destination buffers are
> compatible, so it would be nice if sparse could issue a warning when
> they are not.

I think what you want is:

memcpy(pLE, pBE, len); // warning
memcpy(pBE, pLE, len); // warning
memcpy(pLE1, pLE2, len); // no warning
memcpy(pBE1, pBE2, len); // no warning

That can no be done with stock sparse checking.
Because you need correlation between the first and
second argument.

You can get that kind of feature by extending your own
version of the checking. You just need to implement your
own version of check_memcpy in sparse.c.

>
> 2. Next I tried writing my own memcpy in the hope that I would then get
> warnings in the normal way but got a warning implying that sparse knows
> about memcpy
>
> warning: conflicting types for built-in function "memcpy"
> foo.c: In function "memcpy":

Are you sure it is from sparse not gcc? Sparse has prototypes for
the built-in function "__builtin_memcpy" that is about it.

>

> Is this treatment of void* expected behaviour?

Right. void* means you don't care about the type of the pointer.

BTW, I just find out the Wbitwise is not used any where.
Which means you can't turn Wbitwise off. Should be easy enough to
fix though.

Chris