RE: Unresolved symbol memset

[Michael Smith]

Taking your advice I removed the header memory.h and switched the
include for string.h to be linux/string.h.  This seemed to fix the
problem.  I thank you all for your input and appreciate the time you all
took

Michael

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Tommy Reynolds
Sent: Wednesday, December 05, 2001 2:17 PM
To: Michael Smith
Cc: [e-mail]
Subject: Re: Unresolved symbol memset

More important activities lacking, "Michael Smith" <[e-mail]>
wrote:

> That particular header is included.  As I mentioned, I am using memset
> in other areas of the code, as well as the same file.  If I take this
> one call out of the source, it compiles, links and I am able to
perform
> and insmod correctly.  Below are the headers that are included in the
> file, and the area of the code that is causing the problem.  Let me
say
> that the code, even with this particular call in, compiles and links.
> The problem happens when I go to perform the insmod on it.
> 
> #include <memory.h>
> #include <string.h>
> #include "myownheaders.h"
> 
> 
> void myfunction( void *a, int len )
> {
> ....
> Mymemmove() //used because NdisMoveMemory can not be used
> memset( &a->WORD[NUMWORDS-len], 0, len*4);
> ...
> }

Inside a driver (or module) file, any include reference that doesn't
begin with
either <linux/foo.h> or <asm/foo.h> should always raise a red flag.
There are
user-land header files ("/usr/include") and kernel header files
("/usr/src/linux/include") and never the twain shall meet.

Mixing includes is always a bad idea.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- --
-- --
Tommy Reynolds                               | mailto:
<[e-mail]>
Red Hat, Inc., Embedded Development Services | Phone:  [phone]
307 Wynn Drive NW, Huntsville, AL 35805 USA  | FAX:    [phone]
Senior Software Developer                    | Mobile: [phone]