Accessing via a pointer to 2d array.

[Thes]

Hi all,

I have a 2d float array to which I have declared a pointer thus:

float Matrix[4][3] = {/* snipped initialisation */ };
float (*StoredMatrix)[4][3];
So as to create a copy in a program "registry" of my own devising.

I copy the Marix array as follows:

StoredMatrix = malloc(sizeof Matrix);
if(!StoredMatrix)
{
memcpy((void*)StoredMatrix, (void*)Matrix, sizeof Matrix);
}
else
{ /* take action */ }

My question is whether this is legal, and if so whether it is dangerous?
So far, the copied version dereferences OK using the [] operators - eg
using *StoredMatrix[2][1] etc. I'm not finding K&R helpful on the subject.

Any advice appreciated.
TheS

[Joona I Palaste]

Thes <no*@ctually.myaddress.com> scribbled the following:

Hi all, I have a 2d float array to which I have declared a pointer thus: float Matrix[4][3] = {/* snipped initialisation */ };
float (*StoredMatrix)[4][3];
So as to create a copy in a program "registry" of my own devising. I copy the Marix array as follows: StoredMatrix = malloc(sizeof Matrix);
if(!StoredMatrix)
Surely you mean if (StoredMatrix), or better yet,
if (StoredMatrix != NULL) here? The way you've written here is asking
for trouble.
{
memcpy((void*)StoredMatrix, (void*)Matrix, sizeof Matrix);
}
else
{ /* take action */ } My question is whether this is legal, and if so whether it is dangerous?
So far, the copied version dereferences OK using the [] operators - eg
using *StoredMatrix[2][1] etc. I'm not finding K&R helpful on the subject.

Correcting the obvious bug, I don't see any problem. Arrays are
guaranteed to be contiguous, so you'll get no alignment or offset
problems.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"A bicycle cannot stand up by itself because it's two-tyred."
- Sky Text

[Thes]

Joona I Palaste wrote:

Thes <no*@ctually.myaddress.com> scribbled the following:

Hi all,

I have a 2d float array to which I have declared a pointer thus:

float Matrix[4][3] = {/* snipped initialisation */ };
float (*StoredMatrix)[4][3];

So as to create a copy in a program "registry" of my own devising.

I copy the Marix array as follows:

StoredMatrix = malloc(sizeof Matrix);
if(!StoredMatrix)

Surely you mean if (StoredMatrix), or better yet,
if (StoredMatrix != NULL) here? The way you've written here is asking
for trouble.

Oops - yes, that's exactly what I mean. Sorry about that.

{
memcpy((void*)StoredMatrix, (void*)Matrix, sizeof Matrix);
}
else
{ /* take action */ }

My question is whether this is legal, and if so whether it is dangerous?
So far, the copied version dereferences OK using the [] operators - eg
using *StoredMatrix[2][1] etc. I'm not finding K&R helpful on the subject.

Correcting the obvious bug, I don't see any problem. Arrays are
guaranteed to be contiguous, so you'll get no alignment or offset
problems.

Thanks for the reply.

Thes.

[Sheldon Simms]

On Mon, 10 Nov 2003 16:50:13 +0000, Thes wrote:

I copy the Marix array as follows: [snip] memcpy((void*)StoredMatrix, (void*)Matrix, sizeof Matrix);

The casts to void are unnecessary if you have #included string.h, which
you should do.

[Thes]

Sheldon Simms wrote:

On Mon, 10 Nov 2003 16:50:13 +0000, Thes wrote:

I copy the Marix array as follows:

[snip]

memcpy((void*)StoredMatrix, (void*)Matrix, sizeof Matrix);

The casts to void are unnecessary if you have #included string.h, which
you should do.

Thanks for the tip.

Thes

[Dan Pop]

In <3F**************@ctually.myaddress.com> Thes <no*@ctually.myaddress.com> writes:

I have a 2d float array to which I have declared a pointer thus:

float Matrix[4][3] = {/* snipped initialisation */ };
float (*StoredMatrix)[4][3];

So as to create a copy in a program "registry" of my own devising.

I copy the Marix array as follows:

StoredMatrix = malloc(sizeof Matrix);
if(!StoredMatrix)
{
memcpy((void*)StoredMatrix, (void*)Matrix, sizeof Matrix);
}
This is better written like this:

StoredMatrix = malloc(sizeof *StoredMatrix);
if (StoredMatrix != NULL)
{
memcpy(StoredMatrix, Matrix, sizeof Matrix);
}

Using an explicit test against NULL makes it less likely that you get it
wrong and the casts in the memcpy call are cluttering the code without
buying you anything.
else
{ /* take action */ }

My question is whether this is legal, and if so whether it is dangerous?
So far, the copied version dereferences OK using the [] operators - eg
using *StoredMatrix[2][1] etc. I'm not finding K&R helpful on the subject.

No problems with your code (except for the obvious bug in the if
statement), but it can be improved, so that you can use the
StoredMatrix[2][1] syntax instead of the less natural *StoredMatrix[2][1].

float (*StoredMatrix)[3];
StoredMatrix = malloc(4 * sizeof *StoredMatrix);

Another advantage of this technique is that you can dynamically allocate
"bidimensional" arrays without knowing the number of lines at compile time
only the number of columns must be known.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[CBFalconer]

Dan Pop wrote:

.... snip ...
This is better written like this:

StoredMatrix = malloc(sizeof *StoredMatrix);
if (StoredMatrix != NULL)
{
memcpy(StoredMatrix, Matrix, sizeof Matrix);
}
.... snip ...
No problems with your code (except for the obvious bug in the if

Recalling that Matrix was defined as an array of floats, each of
which may have padding bits and trap values, what guarantees that
those padding bits and trapvalues are independent of the actual
storage location? Thus I suspect that the construct is not
strictly legal, but that the chance of actual problems is
miniscule.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Thes]

CBFalconer wrote:

Dan Pop wrote:

... snip ...

This is better written like this:

StoredMatrix = malloc(sizeof *StoredMatrix);
if (StoredMatrix != NULL)
{
memcpy(StoredMatrix, Matrix, sizeof Matrix);
}

... snip ...

No problems with your code (except for the obvious bug in the if

Recalling that Matrix was defined as an array of floats, each of
which may have padding bits and trap values, what guarantees that
those padding bits and trapvalues are independent of the actual
storage location? Thus I suspect that the construct is not
strictly legal, but that the chance of actual problems is
miniscule.

Further to that: doing some more testing it seems that when using memcpy
to copy the entire array over to the memory pointed to by the pointer,
there was some problems using [] on the dereferenced pointer. That is,
*StoredMatrix[i][j] didn't always equal Matrix[i][j].

If I copied the matrix using a nested loop in i and j strictly setting
*StoredMatrix[i][j] = Matrix[i][j] then, obviously, all was well.

This behaviour was observed using MSVC++6 but not gcc on Linux - so I
expect I'm doing something undefined somewhere...

Anyway, thanks for the replies. Bad coding habits being curbed!
Thes

[Dan Pop]

In <3F***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:

Dan Pop wrote:

... snip ...

This is better written like this:

StoredMatrix = malloc(sizeof *StoredMatrix);
if (StoredMatrix != NULL)
{
memcpy(StoredMatrix, Matrix, sizeof Matrix);
}

... snip ...

No problems with your code (except for the obvious bug in the if

Recalling that Matrix was defined as an array of floats, each of
which may have padding bits and trap values, what guarantees that
those padding bits and trapvalues are independent of the actual
storage location?

The C standard, of course.
Thus I suspect that the construct is not
strictly legal, but that the chance of actual problems is
miniscule.

Wrong. Note that the padding bits are part of the object representation.

4 Values stored in non-bit-field objects of any other object type
consist of n × CHAR_BIT bits, where n is the size of an object
of that type, in bytes. The value may be copied into an object
of type unsigned char [n] (e.g., by memcpy); the resulting
^^^^^^^^^^^^^^^
set of bytes is called the object representation of the value.
Values stored in bit-fields consist of m bits, where m is the
size specified for the bit-field. The object representation is
the set of m bits the bit-field comprises in the addressable
storage unit holding it. Two values (other than NaNs) with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the same object representation compare equal, but values that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
compare equal may have different object representations.

It doesn't hurt to actually consult the standard when elaborating fancy
scenarios...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <3F**************@ctually.myaddress.com> Thes <no*@ctually.myaddress.com> writes:

CBFalconer wrote:

Dan Pop wrote:

... snip ...

This is better written like this:

StoredMatrix = malloc(sizeof *StoredMatrix);
if (StoredMatrix != NULL)
{
memcpy(StoredMatrix, Matrix, sizeof Matrix);
}

... snip ...

No problems with your code (except for the obvious bug in the if

Recalling that Matrix was defined as an array of floats, each of
which may have padding bits and trap values, what guarantees that
those padding bits and trapvalues are independent of the actual
storage location? Thus I suspect that the construct is not
strictly legal, but that the chance of actual problems is
miniscule.

Further to that: doing some more testing it seems that when using memcpy
to copy the entire array over to the memory pointed to by the pointer,
there was some problems using [] on the dereferenced pointer. That is,
*StoredMatrix[i][j] didn't always equal Matrix[i][j].

The bug was elsewhere in your code. The value of *any* object, no matter
how large and complex, can be safely copied with memcpy.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Thes]

Dan Pop wrote:

In <3F**************@ctually.myaddress.com> Thes <no*@ctually.myaddress.com> writes:

CBFalconer wrote:

Dan Pop wrote:

... snip ...
This is better written like this:

StoredMatrix = malloc(sizeof *StoredMatrix);
if (StoredMatrix != NULL)
{
memcpy(StoredMatrix, Matrix, sizeof Matrix);
}
... snip ...
No problems with your code (except for the obvious bug in the if
Recalling that Matrix was defined as an array of floats, each of
which may have padding bits and trap values, what guarantees that
those padding bits and trapvalues are independent of the actual
storage location? Thus I suspect that the construct is not
strictly legal, but that the chance of actual problems is
miniscule.

Further to that: doing some more testing it seems that when using memcpy
to copy the entire array over to the memory pointed to by the pointer,
there was some problems using [] on the dereferenced pointer. That is,
*StoredMatrix[i][j] didn't always equal Matrix[i][j].

The bug was elsewhere in your code. The value of *any* object, no matter
how large and complex, can be safely copied with memcpy.

Dan

Indeed. I've discovered that there is a difference between
*StoredMatrix[i][j] and (*StoredMatrix)[i][j] which suprised me.

What are the rules in these cases?

Thes

[Joona I Palaste]

Thes <no*@ctually.myaddress.com> scribbled the following:

Dan Pop wrote:

In <3F**************@ctually.myaddress.com> Thes <no*@ctually.myaddress.com> writes:

CBFalconer wrote:
Dan Pop wrote:
>This is better written like this:
>
> StoredMatrix = malloc(sizeof *StoredMatrix);
> if (StoredMatrix != NULL)
> {
> memcpy(StoredMatrix, Matrix, sizeof Matrix);
> }

>No problems with your code (except for the obvious bug in the if

Recalling that Matrix was defined as an array of floats, each of
which may have padding bits and trap values, what guarantees that
those padding bits and trapvalues are independent of the actual
storage location? Thus I suspect that the construct is not
strictly legal, but that the chance of actual problems is
miniscule.

Further to that: doing some more testing it seems that when using memcpy
to copy the entire array over to the memory pointed to by the pointer,
there was some problems using [] on the dereferenced pointer. That is,
*StoredMatrix[i][j] didn't always equal Matrix[i][j].
The bug was elsewhere in your code. The value of *any* object, no matter
how large and complex, can be safely copied with memcpy.

Indeed. I've discovered that there is a difference between
*StoredMatrix[i][j] and (*StoredMatrix)[i][j] which suprised me. What are the rules in these cases?

I'm not altogether sure here, but I think that the first means what
element [i][j] of StoredMatrix points at, and the second means element
[i][j] of what StoredMatrix points at.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Normal is what everyone else is, and you're not."
- Dr. Tolian Soran

[Dan Pop]

In <3F**************@ctually.myaddress.com> Thes <no*@ctually.myaddress.com> writes:

Dan Pop wrote:

The bug was elsewhere in your code. The value of *any* object, no matter
how large and complex, can be safely copied with memcpy.

Indeed. I've discovered that there is a difference between
*StoredMatrix[i][j] and (*StoredMatrix)[i][j] which suprised me.

What are the rules in these cases?

The [] operator having higher precedence, *StoredMatrix[i][j] is the same
as *(StoredMatrix[i][j]), which is NOT what you want in order to access
the element on row i, column j. StoredMatrix[i] is already sending you
beyond the array pointed to by StoredMatrix, if i is not 0.

To preserve your sanity, restrict yourself to pointers to "unidimensional"
arrays, as I've shown in my first post in this thread.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[CBFalconer]

Dan Pop wrote:

CBFalconer <cb********@yahoo.com> writes:

.... snip ...

Recalling that Matrix was defined as an array of floats, each of
which may have padding bits and trap values, what guarantees that
those padding bits and trapvalues are independent of the actual
storage location?

The C standard, of course.

Thus I suspect that the construct is not
strictly legal, but that the chance of actual problems is
miniscule.

Wrong. Note that the padding bits are part of the object representation.

4 Values stored in non-bit-field objects of any other object type
consist of n × CHAR_BIT bits, where n is the size of an object
of that type, in bytes. The value may be copied into an object
of type unsigned char [n] (e.g., by memcpy); the resulting
^^^^^^^^^^^^^^^
set of bytes is called the object representation of the value.
Values stored in bit-fields consist of m bits, where m is the
size specified for the bit-field. The object representation is
the set of m bits the bit-field comprises in the addressable
storage unit holding it. Two values (other than NaNs) with
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the same object representation compare equal, but values that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
compare equal may have different object representations.

It doesn't hurt to actually consult the standard when elaborating
fancy scenarios...

Why go through an O(N**N) search when we have you to perform those
correlations :-)

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Dan Pop]

In <3F***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes:

Dan Pop wrote:

It doesn't hurt to actually consult the standard when elaborating
fancy scenarios...

Why go through an O(N**N) search when we have you to perform those
correlations :-)

Maybe because it prevents the brain cells from getting rusty? ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de