Thread: I'm refreshing my memory, and am having strange behavior playing around with pointers

Code:

// array of 2 integers (8 bits)
    int **int_pointer_array = malloc(2*sizeof(int *));

This is an array of two pointers to integers, not to integers.
I run it and got the correct results.

Originally Posted by std10093

Code:

// array of 2 integers (8 bits)
    int **int_pointer_array = malloc(2*sizeof(int *));

This is an array of two pointers to integers, not to integers.
I run it and got the correct results.

You are right, my comment is incorrect, but the idea is still the same. I had co-workers run it as well and get the correct results. I think it's the architecture of my server, looking into it now.

(As an aside, whenever you refer to "bits" in your comments, this should really be "bytes".)

This is strange - 426311680 is 0x19690000, and 0x1969 is 6505, so it's as if you're somehow realigning your read/write by two bytes.

You shouldn't use "main_pointer + 6" - use "main_pointer + sizeof(int *)" as otherwise you'll run into problems if pointers are more than 6 B on your computer.

What optimizations are you using? What system are you compiling on/for (and are they the same?) and what's the size of int and int* on that system/those systems? (i.e. what do you get if you run printf("int: %d, int*: %d\n", sizeof(int), sizeof(int *))

Okay, so I figured out what's happening, but not sure why or how to deal with it.

I modified the code a little bit:

Code:

#include <stdio.h>
#include <stdlib.h>

int main(void){

	//10 byte bank
	char *main_pointer = malloc(10);

	// array of pointers to 2 integers pointers (8 bytes)
	int **int_pointer_array = malloc(2*sizeof(int *));

	// set first integer pointer in array to point to byte 0 in 10 byte bank
	int_pointer_array[0] = (int *) main_pointer;

	// set the second integer pointer in array to point to byte 6 in 10 byte bank
	int_pointer_array[1] = (int *) (main_pointer + 6);

	// assign values
	*int_pointer_array[0] = 6505;
	*int_pointer_array[1] = 5;

	// print values
	printf("The values are %d and %i\n", *int_pointer_array[0], *int_pointer_array[1]);
	printf("The values are %d and %d\n", *int_pointer_array[0], *(main_pointer+4));

	int i = 0;
	for (i = 0; i < 10; i++){
		printf("main_ptr char byte %d, value is : %i\n", i, *(main_pointer + i));
	}

	printf("Pointer[0] is pointing to: %p\n", int_pointer_array[0]);
	printf("Pointer[1] is pointing to: %p\n", int_pointer_array[1]);

	return 0;


}

And the output of said code:

Code:

The values are 6505 and 327680
The values are 6505 and 5
main_ptr char byte 0, value is : 105
main_ptr char byte 1, value is : 25
main_ptr char byte 2, value is : 0
main_ptr char byte 3, value is : 0
main_ptr char byte 4, value is : 5
main_ptr char byte 5, value is : 0
main_ptr char byte 6, value is : 0
main_ptr char byte 7, value is : 0
main_ptr char byte 8, value is : 0
main_ptr char byte 9, value is : 0
Pointer[0] is pointing to: 0x11008
Pointer[1] is pointing to: 0x1100e

So as you can see, instead of the line *int_pointer_array[1] = 5; putting the value 5 at byte 6, it is actually putting it at byte 4, and when it prints it out via the printf, it's actually interpreting it as 0x50000, which is = 327680.

Why is this happening, and what should I do about it?

Thank you for any help.

Originally Posted by JohnGraham

(As an aside, whenever you refer to "bits" in your comments, this should really be "bytes".)

This is strange - 426311680 is 0x19690000, and 0x1969 is 6505, so it's as if you're somehow realigning your read/write by two bytes.

You shouldn't use "main_pointer + 6" - use "main_pointer + sizeof(int *)" as otherwise you'll run into problems if pointers are more than 6 B on your computer.

What optimizations are you using? What system are you compiling on/for (and are they the same?) and what's the size of int and int* on that system/those systems? (i.e. what do you get if you run printf("int: %d, int*: %d\n", sizeof(int), sizeof(int *))

Size of int, and int* both return the value of 4.

Yes, i would normally do as you suggested, main_pointer + sizeof(int *), but the point behind this little script is to leave bits 4 and 5 as dead space, so the code is a little unorthodox.

I'm compiling on a pogoplug, which is using ARMv6l architecture, I believe. Pogoplug Pro/Video/v3 | Arch Linux ARM

And yes, you're evaluation is correct, as you can see from my post above ( I switched values around to make it a little simpler). Not sure why this is happening though.

I get the correct output compiling for x86 natively, but the exact same output as yourself when I cross-compile for ARM5TE.

I think you're running into strict aliasing issues, but I'm not sure why.

(Edited because I said I could get it to work correctly by changing a type but I was using that type wrong, I can't).

Okay, so here's what I've got after some testing - it appears all the writes are being "rectified" to be aligned to a 4-byte boundary, but the reads aren't. I don't know ARM assembler at all, so I don't know why this is.

However, if you're determined to get two bytes between two int values, using a struct like this works:

Code:

struct {
        int  i1;
        char c1;
        char c2;
        int  i2;
} __attribute((packed)) *block = malloc(10);

// Reads/writes like this work for me.
block->i2 = VALUE;

But writing through any int* pointer doesn't work at all. I suspect the use of a properly laid-out struct forces gcc (which is what I assume you're using?) to generate code that's more akin to a memcpy() than a "regular" load/store to get around this because it knows it'll have to.

Now it seems that on my system the write is like two 2 B values getting swapped - i.e. writing like:

Code:

*int_pointer_array[1] = 0xabcd1234;

results in 0x1234abcd being read in printf(). Also if I memcpy() to the correct address, I can't get printf() to read the correct value through a raw pointer, so I suspect reads aren't happening correctly after all. I don't know why this is, but like I said the struct method works for me. If you need to find out, the gcc-help mailing list is probably the next place to go.

What you're doing is strictly illegal.
https://en.wikipedia.org/wiki/Data_structure_alignment
"cast increases required alignment of target type" | Comp.Arch.Embedded | EmbeddedRelated.com

If you try to access data on an unaligned boundary, then what happens next is a roll of the dice.
- it works (as on x86)
- it produces strange results (as on ARM)
- it is an expensive trap into the OS to fix things up
- it is a bus error, and your code is just a smoking ruin of what it once was.

If you're comping with gcc, consider using this flag.

Code:

       -Wcast-align
           Warn whenever a pointer is cast such that the required alignment of
           the target is increased.  For example, warn if a "char *" is cast
           to an "int *" on machines where integers can only be accessed at
           two- or four-byte boundaries.

Whilst __attribute((packed)) offer an easy way out, it does so at the expense of more complicated code. Fetching an unaligned int on ARM would result in two memory reads, a shift left, a shift right and a bit-wise or (compared to just a fetch).

On the X86, the same thing happens in the bloated hardware of the memory access unit (which ARM, being a stripped down RISC doesn't have).

> Okay, so I figured out what's happening, but not sure why or how to deal with it.
The hacky approach to pulling unaligned data out of a data stream is something like
memcpy( &myInt, main_pointer + 6, sizeof(myInt) );

The sound way to do it is

Code:

myInt = 0;  // or your favourite int of a given size
for ( i = 0 ; i < sizeof(myInt) ; i++ ) {
  myInt = (myInt << 8) | main_pointer[6+i];
}

Whilst this seems a rather long winded approach, not only is it immune to alignment issues, it is also immune to Endian issues as well.
Once you've got the loop the right way round for the endian-ess of the input data, it doesn't matter at all what the endian of the host machine is.