473,883 Members | 1,694 Online

# problem with memcpy and pointers/arrays confusion - again

Hi,

pointers and arrays many times, it's a topic that is a little confusing
to me - at least at this moment:

----
1) What's the difference between these 3 statements:

(i) memcpy(&b, &KoefD, n); // this works somewhere in my code

(ii) memcpy(&b[0], &KoefD[0], n); // but this doesn't

(iii) memcpy(b, KoefD, n); // what's the meaning of this then?
N.B: b is defined such that:

double *b = (double *) malloc(sizeof(d ouble) * (n+1));

and

KoefD is an argument to a sub-function that is called from within
main(). It's prototype (in main-function) is something like:

void sub_function(in t n, const double *KoefD);

I understand that this "&" gives the physical address of the pointer
itself... I would assume that was the same thing as &b[0] (the first
element) - but it doesn't seem like it is....
2) Why does this work:

free(indx); // free 1D array

But this doesn't?

free(b);

---------

indx is:
unsigned long *indx = (unsigned long *) malloc( (n+1)*sizeof(un signed
long) );

b is:
double *b = (double *) malloc(sizeof(d ouble) * (n+1));
I hope I don't have to cut down my program in small pieces to show that
these questions are actually some problems I struggle with now and it
might be I misunderstood something, but any comments would be greatly
appreciated...

If I have to, I'll cut my program down so you can just copy/paste, but
it would be much easier if I could figure out the error myself.
Best regards / Med venlig hilsen
Martin Jørgensen

--
---------------------------------------------------------------------------
Home of Martin Jørgensen - http://www.martinjoergensen.dk
Mar 9 '06
39 19673
Jordan Abel <ra*******@gmai l.com> writes:
#if __STDC_VERSION_ _ == 199901l
#define prntZ "z"
#elif SIZE_MAX <= UINT_MAX && sizeof(size_t) <= sizeof(int)
#define prntZ ""
#elif SIZE_MAX == ULONG_MAX && sizeof(size_t) == sizeof(long)
#define prntZ "l"
#else
#error size_t too big
#endif

--
"A lesson for us all: Even in trivia there are traps."
--Eric Sosman
Mar 20 '06 #31
On 2006-03-20, Ben Pfaff <bl*@cs.stanfor d.edu> wrote:
Jordan Abel <ra*******@gmai l.com> writes:
#if __STDC_VERSION_ _ == 199901l

typo.
#define prntZ "z"
#elif SIZE_MAX <= UINT_MAX && sizeof(size_t) <= sizeof(int)
#define prntZ ""
#elif SIZE_MAX == ULONG_MAX && sizeof(size_t) == sizeof(long)
unfortunately, it appears that sizeof doesn't work in a preprocessor
directive - the question is, can I trust the maxes?
#define prntZ "l"
#else
#error size_t too big
#endif

Mar 20 '06 #32
Jordan Abel <ra*******@gmai l.com> writes:
On 2006-03-20, Ben Pfaff <bl*@cs.stanfor d.edu> wrote:
Jordan Abel <ra*******@gmai l.com> writes:
#define prntZ "z"
#elif SIZE_MAX <= UINT_MAX && sizeof(size_t) <= sizeof(int)
#define prntZ ""
#elif SIZE_MAX == ULONG_MAX && sizeof(size_t) == sizeof(long)

unfortunately, it appears that sizeof doesn't work in a preprocessor
directive - the question is, can I trust the maxes?

You can't trust the ranges or the sizes, actually, by my reading.
`long' and `int' could have the same size, range, and
representation, and it would still yield undefined behavior to
print one of them with the other format specifier. This is
because the description of the fprintf function states explicitly
what type arguments must be; it doesn't make any allowance for
equivalent representations .

However, I'd guess that using ranges would work on "normal"
implementations .
--
int main(void){char p[]="ABCDEFGHIJKLM NOPQRSTUVWXYZab cdefghijklmnopq rstuvwxyz.\
\n",*q="kl BIcNBFr.NKEzjwC IxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+= strchr(p,*q++)-p;if(i>=(int)si zeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Mar 20 '06 #33
Dave Thompson <da************ *@worldnet.att. net> writes:
[...]
sizeof, and sizeof(typename ), doesn't standardly work in preprocessor
directives, although there are rumors some compilers support it.

The definitive word on this can be found in an article posted to
comp.std.c in 1998.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 20 '06 #34
Keith Thompson opined:
Dave Thompson <da************ *@worldnet.att. net> writes:
[...]
sizeof, and sizeof(typename ), doesn't standardly work in
preprocessor directives, although there are rumors some compilers
support it.

The definitive word on this can be found in an article posted to
comp.std.c in 1998.

Ah, just the kind of quote to brighten a grey English morning!

Thanks.

--

Predestination was doomed from the start.

Mar 20 '06 #35
Keith Thompson <ks***@mib.or g> wrote:
Martin Jørgensen <un*********@sp am.jay.net> writes:
[...]
I think I know why I did that cast. From
http://en.wikipedia.org/wiki/Malloc :

int *ptr = (int *)malloc(sizeof (int) * 10);

But that cast is wrong, you say? Then somebody should update what's on
wikipedia...

Looks like someone has:

#include <stdlib.h>

/* Allocate space for an array with 10 elements of type int */
/* C++ needs a cast, C strongly discourages it */
int *ptr = malloc(sizeof *ptr * 10);

Anyone taking bets on how long before it's changed back?

Richard
Mar 20 '06 #36
Richard Bos wrote:
Keith Thompson <ks***@mib.or g> wrote:
Martin Jørgensen <un*********@sp am.jay.net> writes:
[...]
I think I know why I did that cast. From
http://en.wikipedia.org/wiki/Malloc :

int *ptr = (int *)malloc(sizeof (int) * 10);

But that cast is wrong, you say? Then somebody should update what's on
wikipedia...

Looks like someone has:

#include <stdlib.h>

/* Allocate space for an array with 10 elements of type int */
/* C++ needs a cast, C strongly discourages it */
int *ptr = malloc(sizeof *ptr * 10);

Anyone taking bets on how long before it's changed back?

Well, when I looked yesterday the comment had been removed, but the code
was still the same. I changed the exit(1) to exit(EXIT_FAILU RE) for them.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Mar 20 '06 #37
On 2006-03-20, Ben Pfaff <bl*@cs.stanfor d.edu> wrote:
Jordan Abel <ra*******@gmai l.com> writes:
On 2006-03-20, Ben Pfaff <bl*@cs.stanfor d.edu> wrote:
Jordan Abel <ra*******@gmai l.com> writes:
#define prntZ "z"
#elif SIZE_MAX <= UINT_MAX && sizeof(size_t) <= sizeof(int)
#define prntZ ""
#elif SIZE_MAX == ULONG_MAX && sizeof(size_t) == sizeof(long)
unfortunately, it appears that sizeof doesn't work in a preprocessor
directive - the question is, can I trust the maxes?

You can't trust the ranges or the sizes, actually, by my reading.
`long' and `int' could have the same size, range, and
representation, and it would still yield undefined behavior to
print one of them with the other format specifier.

As a matter of practice, though, if they both have the same range, and
size_t has the same range as both, size_t is more likely to be unsigned
int than unsigned long. [and, of course, if size_t is NARROWER than int,
you can use int, because it will be promoted]
This is
because the description of the fprintf function states explicitly
what type arguments must be; it doesn't make any allowance for
equivalent representations .

However, I'd guess that using ranges would work on "normal"
implementations .

Mar 20 '06 #38
Jordan Abel <ra*******@gmai l.com> writes:
As a matter of practice, though, if they both have the same range, and
size_t has the same range as both, size_t is more likely to be unsigned
int than unsigned long. [...]

I've seen both `unsigned int' and `unsigned long' as size_t when
GCC is configured in different ways. I wouldn't want to depend
on either.
--
Just another C hacker.
Mar 20 '06 #39
Jordan Abel <ra*******@gmai l.com> writes:
As a matter of practice, though, if they both have the same range, and
size_t has the same range as both, size_t is more likely to be unsigned
int than unsigned long. [...]

I've seen both `unsigned int' and `unsigned long' as size_t when
GCC is configured in different ways on systems where those types
are identical, so I wouldn't want to assume that either one is
size_t.
--
Just another C hacker.
Mar 21 '06 #40

This thread has been closed and replies have been disabled. Please start a new discussion.