Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS XCode3/Xcode4

F

farmerdoug

macrumors 6502a
Original poster
Sep 16, 2008
541
0
I have been running Xcode3 in Xcode4. This morning I started a new project in Xcode4; copied the code; made some changes to the prototyping to avoid warnings and ran the code. I got different results.
I'm I crazy?
 
Yes.

If the results are different, the code/data is different.

What do you mean by you've been running XCode 3 in XCode 4 ? Do you mean you've been running a XCode 3 template project in XCode 4 ?
 
The code was copied from one directory and put in another. The code was written on an old laptop running Xcode 3. Now I am using Xcode 4 on my new machine running Lion. So far, I have checked that both codes are using the same input data - I think they are. Tonight, I will print out intermediate steps. Now, its time for my day job.
 
Granted my problem seems to make little sense. I'm not the best or the most careful programmer. Last night I started over. Made a copy of the code; it ran and gave the same results.
However, first you must know that the code has several almost identical procedures each with its own output. The different results I previously received were different answers from different procedures.

So having now a new working copy, I preceded to make changes. Made changes to the first routine. Basically added a few new arrays, downloaded some additional data and ran the code. No problems.

So I take the entire body of the rewritten procedure and use it to replace the body on the next procedure, change the few lines of code that make the procedure different and run it. SIGABRT. I'm freeing a pointer I haven't allocated memory for. Exact same code as previous procedure. Repeat the procedure- same error.

Try a new approach. Delete the file containing the procedure I'm trying to modify. Replace it with a copy of the working procedure; change the prototyping and get the same error.

Give me a break. The old code exactly the same except without the addition of the few extra arrays keeps chugging along which are being freed in the new code keeps chugging along.
 
So, your issue is that entirely new code with new allocations is receiving SIGABRT ?

If you want us to help, maybe you could post this code. This changes the whole topic now.
 
Thanks for reply.

Yes as far as the code goes, at the moment the SIGABRT is the issue. But I am also interested in the more basic question of how can I cut and paste error free, warning free code and come up with a run time error.

I would like to send the code but unfortunately this code is proprietary. I will probably solve the problem although as I get better my errors get harder to find. Take my posting as a rant as much as anything else. However, if you do have any insights of my problem, I would be grateful to hear them.

One other point: the first working procedure is in three nested for loops. It runs 32 times before the second procedure fails. (Which suggests I check if the second procedure fails on the first call to it or later).

Thanks again.
 
farmerdoug said:
Yes as far as the code goes, at the moment the SIGABRT is the issue. But I am also interested in the more basic question of how can I cut and paste error free, warning free code and come up with a run time error.
Click to expand...

If there's a runtime error it doesn't necessarily generate compile time errors or warnings. That's why they're called runtime errors. ;)

SIGABRT is a memory allocation issue. You're either overflowing an array, writing to unallocated memory or freeing memory that is not yours to free, resulting in zombies.

Run the profiler and do a zombie test first (I think it's CMD-I, look in the RUN menu, I don't have XCode handy here, only my trusty work PC with Windows/Linux).
 
OMG. You consort with the evil empire!!!?

Day job time. Will try your suggests later.
thanks.
 
HUH? Added a print statement to the code to see how many times I can run the failing procedure. It ran. Took the print statement out. It ran again. Closed the code; opened it; it failed; print statement back in, it ran. Closed code. Open ed it with print statement. The offending procedure failed the second time it ran. Same error about pointer not being freed.

Just because you say you are not working for the EVIL EMPIRE... Send ticket to Quebec so that I can come verify the facts.
 
farmerdoug said:
HUH? Added a print statement to the code to see how many times I can run the failing procedure. It ran. Took the print statement out. It ran again. Closed the code; opened it; it failed; print statement back in, it ran. Closed code. Open ed it with print statement. The offending procedure failed the second time it ran. Same error about pointer not being freed.
Click to expand...

Definately sounds like a overflow issue. That's the thing with these kind of errors, they have various effects depending on what you're overwriting in memory and the behavior can change from execution to execution.

farmerdoug said:
Just because you say you are not working for the EVIL EMPIRE... Send ticket to Quebec so that I can come verify the facts.
Click to expand...

What are you on about ? What evil empire do you think "i'm working for" ?
 
Of course I'm talking about Microsoft but just because you tell me you are using Linux on a Windows machine is not enough. I need to come to inspect.
Anyway, it wasn't an overflow so much as an underflow and I'm an idiot. I told you in the beginning that I copied and pasted and only made a few small changes. The few small changes were in critical parts of the code. An index value went below zero and kept on going. Is there a reason why runtime errors can not be more accurate in error reporting? Of course, I should check index values. They are already checked all over the code but how hard is it for a compiler to know that an index value has gone negative?
Anyway thanks for the help. And don't forget those tickets. :)

doug.
 
farmerdoug said:
Of course, I should check index values. They are already checked all over the code but how hard is it for a compiler to know that an index value has gone negative?
Click to expand...

1. Negative array indexes are legal in C. You can write a small program that demonstrates this.

2. A compiler can't know that an index value has gone negative, unless the indexing expression evaluates to a compile-time constant. (And even if it did, a negative index is not illegal, even a compile-time constant one.)

3. If the index expression is only determinable at runtime, then a compiler has no way at all to know the index is negative, because the compiler is not present at runtime. So in that case, the answer is "Impossible".


If you want greater runtime safety, you have to use a language with greater runtime safety. Java sounds like it would fit the bill.
 
Appreciate the lesson. Unfortunately your student is not advanced enough to understand it all. I never would have guessed that c allow negative indicies.

So if I allocate 10 spots in memory for an array, I can do this
for (i = -5; i < 5; i++)
array = ... ?

who would have thunk?

I would need a better reason for learning a new language than run time safety. I'm not doing national security. I don't expect you to be impressed that I know three languages but that's enough. (actually one I'm rusty at, and nobody really knows the other one no matter what they say)
 
farmerdoug said:
I have been running Xcode3 in Xcode4. This morning I started a new project in Xcode4; copied the code; made some changes to the prototyping to avoid warnings and ran the code. I got different results.
I'm I crazy?
Click to expand...

Probably a 32-Bit/64-Bit problem. Make sure you use only fixed width integers, such as:
uint64_t
uint32_t
int64_t
int32_t

instead of:
unsigned int
unsigned int
int
int

More info:
http://www.eetimes.com/discussion/-include/4024913/Introduction-to-fixed-width-integers
 
farmerdoug said:
So if I allocate 10 spots in memory for an array, I can do this
for (i = -5; i < 5; i++)
array = ... ?

who would have thunk?
Click to expand...

Yeah, something like this:

int i; // <-- do not need fixed width integer here
int16_t audio_stream[10];
int16_t *my_audio_stream_ptr = ((int16_t *)audio_stream) + 5;

// ...fill array with data...blah...blah...blah...
for (i = -5; i < 5; i++)
my_audio_stream_ptr = ... ?;

farmerdoug said:
I don't expect you to be impressed that I know three languages but that's enough.
Click to expand...
I speak 2 languages and can write code in 4. My goal is to speak 4 languages and to write code in 8. ;)
 
farmerdoug said:
Appreciate the lesson. Unfortunately your student is not advanced enough to understand it all. I never would have guessed that c allow negative indicies.

So if I allocate 10 spots in memory for an array, I can do this
for (i = -5; i < 5; i++)
array = ... ?

who would have thunk?
Click to expand...


No, of course you can't. That is, unless array is a pointer to an array you've incremented and you're now decaying it back to an array.

Best example code I could come up with that shows proper negative index use and pointer arithmetic in less than 10 minutes :

Code: 
$ cat test.c
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char ** argv)
{
	int array[] = { 1, 2, 3, 4, 5 };
	int * arrayp = array;
	int i = 0;
	
	while(i < 5)
	{
		printf("%d ", *arrayp);
		arrayp++;
		i++;
	}
	printf("\n");
	for(i = -5; i < 0; i++)
	{
		printf("%d ", arrayp[i]);
	}
	printf("\n");
	return EXIT_SUCCESS;
}
$ gcc -o test -Wall test.c
$ ./test
1 2 3 4 5 
1 2 3 4 5

As you can see, we're printing the array the 2nd time by decaying out incremented pointer to an array and using negative indexes to go back to the beginning of it. It prints out what we expect, that is the properly ordered array starting at the first element. BTW, after the while loop, if we access *arrayp or arrayp[0], we're going to be accessing unallocated memory and potentially cause a buffer overflow if we write to it, as it has been incremented beyond the bounds of array[].

Yes, C is that cool :D
 
farmerdoug said:
Appreciate the lesson. Unfortunately your student is not advanced enough to understand it all. I never would have guessed that c allow negative indicies.

So if I allocate 10 spots in memory for an array, I can do this
for (i = -5; i < 5; i++)
array = ... ?

who would have thunk?

I would need a better reason for learning a new language than run time safety. I'm not doing national security. I don't expect you to be impressed that I know three languages but that's enough. (actually one I'm rusty at, and nobody really knows the other one no matter what they say)
Click to expand...


The pointer that is calculated must be within the array.

If p points to the fifth element, then p[-1] will point to the fourth element, and that is fine. P [-6] would be wrong.
 
Some what afraid to ask. But is all this an intellectual exercise in an unintended consequence of C's design or can it serve a real purpose?
 
So in the sense that I asked the question, it is an unintended consequence. Pointer arithmetic is an important part of C - used it myself on occasion; but what code might actual require a negative index; or I have missed something in this discussion.
 
farmerdoug said:
Some what afraid to ask. But is all this an intellectual exercise in an unintended consequence of C's design or can it serve a real purpose?
Click to expand...

In languages like Pascal you could always have negative array indices, because arrays could start at any point, like "array [-10 .. +10] of integer" or something similar. So one use case would be that you _want_ an array that doesn't start at zero; for the array above you would declare an array with 21 elements, make a pointer to the tenth element, and use indices from -10 to +10.

The other common use case is where you have a pointer p that doesn't point to an array, but to one element of the array. Then p [-1] is the previous element, and p [+1] is the next element. In your code, you very often access p [index - 1], p [index] and p [index + 1]. If instead you had a pointer q = p + index, you would use p [-1], p [0] and p [1].
 
farmerdoug said:
So in the sense that I asked the question, it is an unintended consequence. Pointer arithmetic is an important part of C - used it myself on occasion; but what code might actual require a negative index; or I have missed something in this discussion.
Click to expand...

I gave you an example. A pointer used as a cursor for an array, but for which you want to use previous values by decaying it to an array for easier syntax reading.

You want a real world example ? I have none to offer. It's just one of those things where one day you'll be sitting in front of a problem, and it'll suddenly be obvious you need a negative index.

As for why not just use an array and indexes instead of a pointer and cursors ? Well, pointers with arithmetics is just more efficient (think of the 70s when this stuff was invented) :

Both of these achieve the same thing if they are initiliased to do so (increment the value by one of the next value stored in an array, but look at the assembly produced for each :

Code: 
arrayp++; *arrayp++;

movl    %eax, -4(%ebp)
addl    $4, -4(%ebp)
addl    $4, -4(%ebp)

Code: 
i++; array[i]++;

addl    $1, -4(%ebp)
movl    -4(%ebp), %eax
movl    -24(%ebp,%eax,4), %eax
leal    1(%eax), %edx
movl    -4(%ebp), %eax
movl    %edx, -24(%ebp,%eax,4)

That should make it more clear why C allows such things as pointer arithmetic and decaying.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back