NO

Author Topic: Pointer Problem?  (Read 4731 times)

Max_Power_Up

  • Guest
Pointer Problem?
« on: August 22, 2007, 08:35:05 AM »
Good Morning Everybody.

I seem to be having a very basic problem, Im sure this must be one of the
most common problems in the world.

I've been programming in C for a while now and I simply love the new
debugger thats built into PellesC IDE
Well, the problem Im having is with a function call to a .dll that I've written.

The DLL contains two functions :
Code: [Select]
typedef struct tagRGBT
{
unsigned char R;
unsigned char G;
unsigned char B;
}RGBT;


void WINAPI (dllexport )func1(char *name)
{
strcpy(name,"this is a test");
}
void WINAPI (dllexport)func2(RGBT *bits)
{
int i;
for(i =0 ; i < 256 ; i++)
    {
       bits[i].R = 255;bits[i].G = 255; bits[i].B = 255;
   }

}



The only problem with this code is that when I call it using :

Code: [Select]
func1(&mylocalarray);
func2(&mylocalrgbtarray);

then *mylocalarray* gets updated with the correct values, but
the *mylocalrgbtarray* does not even get passed properly,
is there any standard limit to the types of pointers that we
can pass into dll's or the memory mapping modes or something?
Some help would be appreciated, I will post the full source once I get
confirmation that somebody is actually reading these forums lol!

Thanks again Pelle for the great IDE...
[/color]

Diddl

  • Guest
Re: Pointer Problem?
« Reply #1 on: August 22, 2007, 09:37:06 AM »
it is not the same thing. first example is a pointer to char. second is a pointer to a struct (not a pointer to a struct array).

I suppose it works fine for i=0.

Code: [Select]
by incrementing i it grows to 1.
bits[i] means *(bits +i).
bits is a pointer, and length of a pointer in Pelles for win32 is 4 byte.
*(bits +1) points to an address 4 bytes after bits.
*(bits +2) points to an address 8 bytes after bits.

I suppose (bits +1) points in middle of your structure.

sorry my english is bad, I hope you understand me.

« Last Edit: August 22, 2007, 01:17:12 PM by Diddl »

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Pointer Problem?
« Reply #2 on: August 22, 2007, 10:08:55 AM »
Yes Diddl there is something wrong the way Max_Power_Up have defined the variables (or the way he pass them).
What is the definition of "mylocalarray" and "mylocalrgbtarray" ?
(post a sample of your code).
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

Max_Power_Up

  • Guest
Re: Pointer Problem?
« Reply #3 on: August 22, 2007, 03:02:54 PM »
Code: [Select]
//these functions are in the dll...


int WINAPI OPVisualizationDetails(char *name,int bflen)
{
//name = malloc(strlen(OUR_VIS_NAME)+1);
int terminator = 0;
int ourbflen = strlen(OUR_VIS_NAME);
if(ourbflen > bflen)
terminator = bflen;
else
terminator = ourbflen;

int robocop;
for(robocop =0 ; robocop < terminator ; robocop++)
name[robocop] = OUR_VIS_NAME[robocop];
//strcpy(name,OUR_VIS_NAME);
//we malloc it and our 'parent' frees it.
return 0;
}

int WINAPI OPVisualizationRender(unsigned char *bits, float *spectrum, int w, int h)
{
//automatic...
memset(bits,255,(w * h  * 3));

//manual
//unsigned char * p = (unsigned char *)bits;

int i;
for(i = 0 ; i < (256) ; i++)
{
//*p++ = (unsigned char)196;
bits[i] = (unsigned char) 64;
// bits[i] = 63;
}
//do something that will show on the screen...
return 0;
}




//these functions are in the calling code :

MI_VISUALIZATIONS[MI_CURRENTVIS].VIS_RENDER((unsigned char *)MEDIA_INFORMATION.MI_SPEC_IMG.I_PIXELS,
(float *)MEDIA_INFORMATION.MI_SPECTRUM,
(int) MI_SPEC_BM_W,
(int) MI_SPEC_BM_H);

//the VIS_RENDER is actually the pointer to that function
//since I stepped through it with the debugger and it is entering the function
//the only problem is that it does not set the values for the bit... whic is :


typedef struct tag_RGBT
{
unsigned char R;
unsigned char G;
unsigned char B;
}RGBT;

typedef struct tag_IMG
{
int I_W;
int I_H;
int I_X;
int I_Y;
RGBT *I_PIXELS;
}IMG;

which doesn't work since I get the first function (OPVisualizationDetails) to
input the correct values for us (OUR_VIS_NAME) is defined as "OurFirstVis", and that bit is working... I can't for the life of me figure it out...please help...?

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Pointer Problem?
« Reply #4 on: August 22, 2007, 04:04:13 PM »
I think that there is a little mess here.  ::)
You define a structure of three chars, the colors, and pass it as a char pointer to a function to represent a multidimensional array of pixel structures.  :P Am I correct ?
Then you access sequencially the colour components treating them as a contiguous array of bytes.
Have you considered the packing that the compiler apply?
The structure RGBT occupy 12bytes not three, because by default the compiler alignes on DWORD boundary unless you instruct it to behave differently.
As first option modify the structure declaration applying packing pragma:
Code: [Select]
#pragma pack(1) //No alignement
typedef struct tag_RGBT
{
unsigned char R;
unsigned char G;
unsigned char B;
}RGBT;
#pragma pack() //Restore default alignement
Now your scanning scheme should work accessing the correct structure members.
Anyway I suggest to use a more direct approach passing a structures pointer, and accessing directly the members.
Be sure to recompile all the sources after modification or a different alignement btween modules will crash the program.
« Last Edit: August 22, 2007, 04:09:33 PM by frankie »
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

Max_Power_Up

  • Guest
Re: Pointer Problem?
« Reply #5 on: August 22, 2007, 04:22:00 PM »
Well, thank you very much for tht insight :)

The reason Im doing it like this is because I was using a structure pointer and it
still didn't work, thats why I tried doing it this way, would I have to define
a RGBT ** , in order to point to a structure array , or can I just use the first
member and hope the sequential access will work?
Hey - I followed your advice closely - the problem is now fixed :) ,
I am discovering other bugs though lol! So the PellesC OpenPlayer has
to take a back seat till I can track down those bugs and
squash them - but the advice on passing a struct pointer was perfect
thank you :)

This is the application Im working on :

« Last Edit: August 22, 2007, 05:20:34 PM by Max_Power_Up »

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Pointer Problem?
« Reply #6 on: August 22, 2007, 06:40:52 PM »
An array is always referred as the address of the first element, also for multidimensional arrays. So passing a pointer to an object, int or char or a structure, acts like a pointer to a single element if you use it directly, or as an array of elements if you access them with array notation:
Code: [Select]
int *Int;
struct foo{
  char a;
  char b:
  char c;
};
struct foo *MyFoo;

void test(void)
{
  int i;

  MyFoo = malloc(sizeof(struct foo) * 100);  //Allocate dynamically an array of 100 structs
  Int      = malloc(sizeof(int) * 100);           //Allocate dynamically an array of 100 int's

  for (i=0; i<100; i++)
  {
     Int[i] = i;
     MyFoo[i].a = Int[i] / 2;
     MyFoo[i].b = Int[i] / 4
     MyFoo[i].c = Int[i] / 8;
  }
}
You cannot pass a poiter to an array statically declared:
Code: [Select]
int i[100];
  .....
  test(&i);     //ERROR!!!
  test(i);       //OK! The name of a static array is a pointer to the first element
  test(&i[0])  //OK! We are passing the address of first element
A definition like:
Code: [Select]
  char **p;defines a pointer of pointers meaning that an object is a pointer to another pointer that in turn points to the object, or could mean that you have an array of pointers that points to an array of elements (the address of element 0 of each array):
Code: [Select]
  char **p;
  char message1[16] = "hello"
  char message2[16] = "C language"
  char message3[16] = "world!"

void foo(void)
{
   p = malloc( 3 * sizeof(char *));  //Allocate the array of pointers (3 elements)
   p[0] = message1;
   p[1] = message2;
   p[2] = message3;
}
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide