RE: Question on memcpy()

RE: Question on memcpy()

[Huber, George K RDECOM CERDEC STCD SRI]

Wen wrote,

>struct sample A, B;
>...
>...
>memset(&A, 0, sizeof(sample));
>memcpy(&A, (char *)&B, sizeof(sample));
>...
>I could not understand why the second argument is (char *)&B, but not &B.
>I think it should be &B. 

I would have to agree with you that the second argument should be just &B.
If 
you were going to cast it to anything, I would cast it to const void*.  I
recall 
that any pointer type may be promoted to a void-pointer by the compiler,
although
my memory is a littel fuzzy on this.  

>Sometimes I found A is all zero. but B is not all zero in fact.  
>Is it due to the second argument (char *)&B?

I would be more suspect of the third argument, I beleive that the argument
to
sizeof should be `struct sample' not just `sample' (I am not sure how the
compiler
will interpret the type sample).  I would code the above two lines in one of
the 
following ways,

method (1):
memset((void*)&A, 0, sizeof(struct sample))
memcpy((void*)&A, (const void*)&B, sizeof(struct sample))

method (2):
memset((void*)&A, 0, sizeof(A))
memcpy((void*)&A, (const void*)&B, sizeof(B))

Note: the explicit cast are probably unnecessary, I do them for two reasons.
First,
      I think it improves the readability of the as it is clearly apparent
what type
      of casts are going one.  Secondly, I always run my source code though
severl 
      `lint' checkers and one will always throw a warning about a conversion
of 
      pointer to sometime to void*.  Doing the explicit casts will cause the
warning 
      to be suspressed.

George.

Re: Question on memcpy()

[Charlie Gordon]

"Huber, George K RDECOM CERDEC STCD SRI" <George.K.Huber@us.army.mil> wrote
in message
news:E3E30069B061524E90BCEE4417E3066113852B@monm207.monmouth.army.mil...
> Wen wrote,
>
> >struct sample A, B;
> >...
> >...
> >memset(&A, 0, sizeof(sample));
> >memcpy(&A, (char *)&B, sizeof(sample));
> >...
> >I could not understand why the second argument is (char *)&B, but not &B.
> >I think it should be &B.
>

This is correct, I suspect this cast comes from the programmer ancient
belief that memcpy should be passed char pointers (confusingly refered to as
byte pointers).  Since it is defined to take (void *, const void*, size_t) ,
passing it any type of pointer is fine, including superfluous casts.

It should be noted that while the initialization to 0 required a call to
memset, copying the raw contents of une struct to another can be done more
efficiently (usually) in C by writing:

A = B;

as far as why sizeof(sample) is accepted at all by the compiler, there 3
possible explanations:

- there is a typedef for sample, at it better be defined to struct sample.
- there is a variable by the name sample in scope, and it better be an
instance of struct sample.
- there is a #define defining the identifier sample to something valid as an
operand to sizeof.  Again, it better be consistent with the use in these 2
lines.

It would be better to make no assumptions about the types of A and B and
write:

memset(&A, 0, sizeof(A));
...
A = B;

This way, the compiler will protest if A and B types don't match, and will
compute the right size for A no matter what type it's defined to be.

Chqrlie.

RedHat Itanium 64 GCC 3.2.3 linking problems

[sheetal fegde]

Hi,

I am facing some problem while linking using gcc-3.2.3

Machine Information
RedHat  IA64
Linux  2.4.21-4.EL #1 SMP Fri Oct 3 17:29:39 EDT 2003
ia64 ia64 ia64 GNU/Linux

g++/gcc information
> gcc -v
 Reading specs from
/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
 Configured with: ../configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --
enable-__cxa_atexit --host=ia64-redhat-linux
 Thread model: posix
 gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20)

>g++- v
Reading specs from
/usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-shared --enable-threads=posix
--disable-checking --with-system-zlib
--enable-__cxa_atexit --host=ia64-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20)


I am trying to build some application with oracle oci,
while linking I am getting following errors.
I feel there is no worng with my code as it works with
gcc 2.96, when i try with 3.2.3 it gives following
problems..

gcc  -c -g -Wno-deprecated -DROGUE6 -DRW_MLS_LIBRARY
-DUSE_SOURCEPRO
-D_RWCONFIG_LINUXGCC323K2421DEBUG_NtvSTL_NoThr_64bit_sd
-DFULL_ORACLE8OCI -DOBT -DREMOTE_HOST_BACKUP -DLINUX
-DDEBUGIO -D_GNU_SOURCE -D__LP64__   -I../oracle/mml 
-o /usr/oracle/OBTBld/obj/obacktrack/lib/mmlIO.o 
../oracle/mml/mmlIO.c 

DtCSharedArchive
/usr/oracle/OBTBld/obj/obacktrack/lib/libobk.so 

#	g++  -Xlinker -G  -static -g  -o 
/usr/oracle/OBTBld/obj/obacktrack/lib/libobk.so 
/usr/oracle/OBTBld/obj/obacktrack/lib/mml.o
/usr/oracle/OBTBld/obj/obacktrack/lib/mmlChlCommn.o
/usr/oracle/OBTBld/obj/obacktrack/lib/mmlIO.o  ;
	g++  -Xlinker -G   -o 
/usr/oracle/OBTBld/obj/obacktrack/lib/libobk.so 
/usr/oracle/OBTBld/obj/obacktrack/lib/mml.o
/usr/oracle/OBTBld/obj/obacktrack/lib/mmlChlCommn.o
/usr/oracle/OBTBld/obj/obacktrack/lib/mmlIO.o  ;

/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x31): In
function `__libc_csu_init':
: undefined reference to `__init_array_start'
/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x32): In
function `__libc_csu_init':
: undefined reference to `__init_array_end'
/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x40): In
function `__libc_csu_init':
: undefined reference to `__init_array_start'
/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0x41): In
function `__libc_csu_init':
: undefined reference to `__init_array_end'
/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0xd1): In
function `__libc_csu_fini':
: undefined reference to `__fini_array_start'
/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0xe0): In
function `__libc_csu_fini':
: undefined reference to `__fini_array_end'
/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0xf0): In
function `__libc_csu_fini':
: undefined reference to `__fini_array_start'
/usr/lib/libc_nonshared.a(elf-init.oS)(.text+0xf1): In
function `__libc_csu_fini':
: undefined reference to `__fini_array_end'
/usr/bin/ld:
/usr/oracle/OBTBld/obj/obacktrack/lib/libobk.so:
hidden symbol `__fini_array_end' isn't defined
collect2: ld returned 1 exit status

What is going wrong? I feel this some problem in
glibc.
can somebody help me on this.
Thanks,
Sheetal.



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Question on memcpy()

[Wen Guangcheng]

Hello Gurus,

I am trying to fix a bug in a  code. I found something like this,

struct sample A, B;
...
...
memset(&A, 0, sizeof(sample));
memcpy(&A, (char *)&B, sizeof(sample));
...
I could not understand why the second argument is (char *)&B, but not &B.
I think it should be &B. 

Sometimes I found A is all zero. but B is not all zero in fact.  
Is it due to the second argument (char *)&B?

Any comment is appreciated and thanks in advance.

Best regards,

--Wen