[SOLVED] Problem with Pointers!!! Please Help.

[theHobbit]

Hi i'm having some problem trying to port a windows app to the PSP.

Doing some debugging I have found the problem, and it is something like this:

I'm reading the data and size of a file with this func:

Code: Select all

char *getFileData(char *filename, long *size)
{

    FILE *f;
    char *data;
	size_t readbytes;


    f = fopen(filename, "rb");
    if (f == NULL) {
		return NULL;
    }


	fseek(f, 0L, SEEK_END);
    (*size) = ftell(f);
    rewind(f);

    data = new char [*size];

    readbytes = fread(data, *size, sizeof(char), f);

    fclose(f);

    return(data);
}

Now I pass that data and size to this function:

Code: Select all

int load_xm( const unsigned char *data,  unsigned int size ) 
{
   ...
}

And there it reads the data doing a lot of casting:

Code: Select all

unsigned int dwHdrSize = *((unsigned long *)(data + 60));
unsighed short rows =*((unsigned short *)(data+336));

Now this is taken from the libmodplug code, i'm using Visual Studio 2005 and was able to compile and run the app fine in windows, but the PSP crashes when doing some of the castings from above. Can anyone can help?

[pspZorba]

Are you sure that you have at least 336 char in data ? ( as you are accessing data+336 ...).

If it's not the case, sometime it can give you something coeherent sometines not ...
You can check as well readbytes

[theHobbit]

yep, the file size is about 500 kb. What bothers me is that it works fine in windows. I think the problem is with the type casting. thanks for the reply!

[Jim]

The code you have posted looks correct, so you need to post more. The casting is fine.

Jim

[jimparis]

Most likely an alignment issue. Memory access must be naturally aligned on the PSP.

[theHobbit]

Thanks!, yep it was a memory alignment issue. I didn't know a lot about it but doing some research I found a some code to fix it.

Now i replaced all the pointer casting with this:

Code: Select all

#define READU16&#40;X&#41;		 &#40;&#40;&#40;&#40;unsigned short&#41;&#40;&#40;X&#41;&#91;0&#93;&#41;&#41;<<0&#41; | \
                          &#40;&#40;&#40;unsigned short&#41;&#40;&#40;X&#41;&#91;1&#93;&#41;&#41;<<8&#41; &#41;

#define READU32&#40;X&#41;		 &#40;&#40;&#40;&#40;unsigned int&#41;&#40;&#40;X&#41;&#91;0&#93;&#41;&#41;<<0&#41; | \
                           &#40;&#40;&#40;unsigned int&#41;&#40;&#40;X&#41;&#91;1&#93;&#41;&#41;<<8&#41; | \
                           &#40;&#40;&#40;unsigned int&#41;&#40;&#40;X&#41;&#91;2&#93;&#41;&#41;<<16&#41; | \
                           &#40;&#40;&#40;unsigned int&#41;&#40;&#40;X&#41;&#91;3&#93;&#41;&#41;<<24&#41;&#41;

unsigned int dwHdrSize = READU32&#40;data + 60&#41;; 
unsighed short rows = READU6&#40;data+336&#41;;

And now it's working fine. Thanks everyone.

[DoctorRockit]

Actually the solution you posted does not deal with alignment, but rather with little-endian to big-endian conversion (or vice versa).

See:
http://en.wikipedia.org/wiki/Data_structure_alignment

versus

http://en.wikipedia.org/wiki/Endianess

[terryxq]

Actually the solution you posted does not deal with alignment, but rather with little-endian to big-endian conversion (or vice versa).

See:
http://en.wikipedia.org/wiki/Data_structure_alignment

versus

http://en.wikipedia.org/wiki/Endianess

I don't think so. macro READU32/16 uses for le, psp is le.

[DoctorRockit]

Actually the solution you posted does not deal with alignment, but rather with little-endian to big-endian conversion (or vice versa).

I don't think so. macro READU32/16 uses for le, psp is le.

Pardon me, you're right. The byte-wise access solves the alignment problem.