[Fredrikp]

I have just started with cocoa programming and making a little test program just for learning but now it quits "due to signal 10 (SIGBUS)".

The code:

Code:
NSArray *keyArray, *vArray;
NSDictionary *aFile;
keyArray = [[NSArray alloc] initWithObjects:@"Number", @"Name"];
vArray = [[NSArray alloc] initWithObjects:@"5", @"Fredrik"]; // It's here the error occurs
aFile = [[NSDictionary alloc] dictionaryWithObjects:vArray forKeys:keyArray];
    
[files addObject:aFile];

I have read that it occurs because of you try to write in the memory where you not allowed to but i don't know why it occurs there. Any ideas?

[sadie]

Signal 10, as far as i can tell, is the equivalent of Java's NullPointerException - ie, you're trying to get at the contents of an object that's set to null, and so doesn't have any contents.

I have no idea why it's happening there, but all i can say is to try the debugger. set a breakpoint a few lines before it (by clicking in the margins), compile and hit 'Debug'. Then watch each of the values as you walk through.

[lindberg]

Originally posted by Fredrikp:
I have read that it occurs because of you try to write in the memory where you not allowed to but i don't know why it occurs there. Any ideas?

In C, variable-argument functions (and ObjC methods) don't know how many arguments they're given, so they need some other way to tell when the argument list is over. Each vararg routine needs to set its own policy on that. printf() and NSString's -initWithFormat: methods can tell by the number of replacement tokens in the format string. In the case of NSArray's -initWithObjects:, it's the presense of a "nil" argument -- i.e., it keeps reading arguments until it finds nil. If you don't put a nil in there, there's no telling what could happen, other than you'll likely get a bus error or segmentation fault.

So, just change the two lines to:

keyArray = [[NSArray alloc] initWithObjects:@"Number", @"Name", nil];

vArray = [[NSArray alloc] initWithObjects:@"5", @"Fredrik", nil];

[sadie]

you know, that really is a dumb system. wouldn't it be better if the compiler just generated a nil at the end of the list whenever it gets variable arguments? It needn't have any effect on methods who use something else to decide on the length, because they wouldn't bother looking at it.

Ok, so it's arrogant for a two bit little web coder to be telling ANSI what they should do - but that doesn't stop it being dumb.

[ali]

Variable argument lists have always been a bit troublesome in C... Best to limit their use as much as possible.


I suppose one issue with putting a NULL automatically at the end could be that if the compiler did not see a declaration for the function, it wouldn't do this, and folks who are used to this behavior might be even more confused. In general C is fairly rigid in its rules, and it's probably best for it to stay this way. It just needs to be made it clear in the declaration of functions like this that a NULL is needed.


Ali