Thread: Warning when building!

Originally posted by Polymorphic OOP
yup, my mistake, sorry about that. It's too late at night here, heh

unsigned char* thru_ptr;

thru_ptr = map[PartIndex]+1;

Why were you adding 4!? that would put you four pointers ahead, not 1 pointer ahead. Pointer arithmetic goes by the size of the type being pointed to. Using + 1 will move you sizeof( unsigned char* ) bytes ahead, which will usually be 4 bytes. If you add 4 like your example, you'd actually be adding 4 * sizeof( unsigned char* ) bytes, whihc would usually be 16 bytes.

The only code that is working properly is:

unsigned char* thru_ptr;

* (int *) thru_ptr = (int)(map[PartIndex]+4 );

I am adding 4 because thru_ptr is defined as char, at least I think so and it works ;-)

if thru_ptr is defined as a char, then you are not coding properly. Also, that wouldn't affect the arithmetic part on the right.

Originally posted by Polymorphic OOP
if thru_ptr is defined as a char, then you are not coding properly. Also, that wouldn't affect the arithmetic part on the right.

It's defined as char because 99% of the things I want to save (read MIDI events) is bytes.

Here is the memory area with the pointer to the part and another pointer that points to the first byte after itself (where the first MIDI bytes is to be saved):

(gdb) x/32 map
0x15a1030: 0x01893000 0xffffffff 0xffffffff 0xffffffff
0x15a1040: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0x15a1050: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0x15a1060: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0x15a1070: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0x15a1080: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0x15a1090: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
0x15a10a0: 0xffffffff 0xffffffff 0xffffffff 0xffffffff

(gdb) x/32 map[0]
0x1893000: 0x01893004 0x00000000 0x00000000 0x00000000
0x1893010: 0x00000000 0x00000000 0x00000000 0x00000000
0x1893020: 0x00000000 0x00000000 0x00000000 0x00000000
0x1893030: 0x00000000 0x00000000 0x00000000 0x00000000
0x1893040: 0x00000000 0x00000000 0x00000000 0x00000000
0x1893050: 0x00000000 0x00000000 0x00000000 0x00000000
0x1893060: 0x00000000 0x00000000 0x00000000 0x00000000
0x1893070: 0x00000000 0x00000000 0x00000000 0x00000000

You are missing the point completely. The right side of that assigment does NOT result in a char, it results in a POINTER to an unsigned char. If you want the data to be a an unsigned char, then map should be defined as a pointer to an unsigned char NOT a pointer to a pointer to an unsigned char. Either that or you should dereference the pointer before assigning. Your typecasting makes absolutely no logical sense.

edit:

pointer that points to the first byte after itself

Why would you have a pointer always point to the first byte after itself? that doesn't really make any sense to do.

Originally posted by Polymorphic OOP
You are missing the point completely. The right side of that assigment does NOT result in a char, it results in a POINTER to an unsigned char. If you want the data to be a an unsigned char, then map should be defined as a pointer to an unsigned char NOT a pointer to a pointer to an unsigned char. Either that or you should dereference the pointer before assigning. Your typecasting makes absolutely no logical sense.

edit:



Why would you have a pointer always point to the first byte after itself? that doesn't really make any sense to do.

Well, I can't comment the first thing you wrote because I am new to C programming and don't understand at this moment what you mean.

But I can tell why I have a pointer that points to the first byte after itselfs.

First of all, the pointer does NOT always point to the first byte after itselfs. Example:

CoreMIDI works by asigning a timestamp value to the MIDI message. I send that timestamp and MIDI message to CoreMIDI. That's the only thing my app must do. To send this MIDI message out to my interfaces is a thing Mac OS X does all by itself. So I can que a lot of MIDI events at different timestamps and OS X just sends them out at exactly the right time. I don't even have to que them in timestamp order. OSX does that for me.

So why the pointer? I have a timer that wake up once every second. This code is que'ing MIDI messages to be sent out by OS X sometime in the near future (within 2 sec). There are at least 2 options to do that. Either search all timestamps from the beginning until we find the right one to send out (I will not need the pointer in that case, but it will take a long time to search every part from the beginning). Or save a pointer so the next time the timer fire we just get that pointer and we are at the right place in the part very quick.

I hope that makes sense to you :-)

Originally posted by electrolove
Well, I can't comment the first thing you wrote because I am new to C programming and don't understand at this moment what you mean.

But I can tell why I have a pointer that points to the first byte after itselfs.

First of all, the pointer does NOT always point to the first byte after itselfs. Example:

CoreMIDI works by asigning a timestamp value to the MIDI message. I send that timestamp and MIDI message to CoreMIDI. That's the only thing my app must do. To send this MIDI message out to my interfaces is a thing Mac OS X does all by itself. So I can que a lot of MIDI events at different timestamps and OS X just sends them out at exactly the right time. I don't even have to que them in timestamp order. OSX does that for me.

So why the pointer? I have a timer that wake up once every second. This code is que'ing MIDI messages to be sent out by OS X sometime in the near future (within 2 sec). There are at least 2 options to do that. Either search all timestamps from the beginning until we find the right one to send out (I will not need the pointer in that case, but it will take a long time to search every part from the beginning). Or save a pointer so the next time the timer fire we just get that pointer and we are at the right place in the part very quick.

I hope that makes sense to you :-)

Maybe it's a better idea to have 2 separate pointer lists. First list for 1024 pointers to different memory areas where the part is recorded. And the second list for 1024 pointers that is the actual play pointer?

Better or worse?

just make a struct which has both and make a single array of those