Help me make my new variant! (please!)

[Julian]

This looks like a bug in slot_by_name:

int slot_by_name(struct player *p, const char *name)
{
	int i;

	/* Look for the correctly named slot */
	for (i = 0; i < p->body.count; i++) {
		if (streq(name, p->body.slots[i].name)) {
			break;
		}
	}

	/* Index for that slot */
	return i;
}

If the name isn’t valid, you run off the end of the loop, and i is body.count.

Then this bad index is fed to:

struct object *slot_object(struct player *p, int slot)
{
	/* Ensure a valid body */
	if (p->body.slots && p->body.slots[slot].obj) {
		return p->body.slots[slot].obj;
	}

	return NULL;
}

The test on body.slots[slot].obj is pointing off the end of the array, and you return… something

slot_by_name() should be returning i where it breaks, and returning an error value at the end, probably -1, and slot_object() should be checking that i is within 0<=I<body.count

[Nick]

slot_by_name() should be returning i where it breaks, and returning an error value at the end, probably -1, and slot_object() should be checking that i is within 0<=I<body.count

I'm actually going to be more hard-core than that - I've put asserts in both places in the latest update.

[will_asher]

It looks like most people didn't notice my edit at the bottom of the post:

EDIT: I think I fixed the problem. Apparently the name of the slot is "arm" not "shield"...

[Pete Mack]

@Julian- 0xDDDDDDD is not -1. I suspect it is uninitialized memory left as a buffer by debug allocator.

[Julian]

@Julian- 0xDDDDDDD is not -1. I suspect it is uninitialized memory left as a buffer by debug allocator.

Almost certainly — whatever was after body.slots in memory was pointing to uninitialized memory when read as an object.

-1 (or something clearly wrong that can be tested for) is what slot_by_name() should’ve been returning when the name didn’t map to a slot.

[Pete Mack]

NULL is the usual. But it is immaterial, since Nick will use a hard assertion.

[Julian]

NULL is the usual. But it is immaterial, since Nick will use a hard assertion.

It’s returning an index, not a pointer.

[will_asher]

Quick question:

Say you have:

if ((something) || (get_check(really?))) {
do_stuff();
}

If (something) is true, will it still ask you the get_check question?

[Nick]

Quick question:

Say you have:

if ((something) || (get_check(really?))) {
do_stuff();
}

If (something) is true, will it still ask you the get_check question?

I believe the answer is no, but it's just possible it's compiler dependent - I'm not the world's greatest C expert.

[Pete Mack]

No, the second clause will not be executed. (If you use a single |, it will.)

Quick question:

Say you have:

if ((something) || (get_check(really?))) {
do_stuff();
}

If (something) is true, will it still ask you the get_check question?

[will_asher]

cool. thanks.

[Pete Mack]

BTW, if you do decide to use boolean arithmetic (|, &, ~, ^) for any reason, always use parentheses.

   x == 1 | y

is not synonymous with

  ( x == 1)| (y)

Even if the unparenthesized code is correct, anyone reading it will flag it as a likely error (and the compiler will warn.)

[Julian]

No, the second clause will not be executed. (If you use a single |, it will.)

I’d not recommend using bit-operators in if clauses like this. (They’ll _work_ , at least most of the time, but it’s not what they’re for.)

If you want the second part of your or to evaluate regardless, either rearrange things, or just evaluate it into temporary variable first.

[Julian]

I believe the answer is no, but it's just possible it's compiler dependent - I'm not the world's greatest C expert.

As Pete said, || is guaranteed to only evaluate the second part if the first is false.

This is also true of &&. It must short-circuit evaluation if the first part is false.

If (self_destruct_flag && initiate_self_destruct()) {
    printf("Ten seconds remain";
}

Is not going to blow you up unexpectedly.

(I do not, however, suggest writing your doomsday device in C. Use a safer language.)

[will_asher]

Today when I opened up Visual Studio to work on RubberBand, it gave me a ton of errors saying "pointer to incomplete class type is not allowed". These errors weren't there yesterday. I hadn't changed anything before those errors appeared and it seems to build and run just fine. Does anyone know why it might suddenly give me all these errors that weren't there when I closed VS yesterday?

EDIT: So I went on working on Rubberband ignoring the errors for now, and after a while they disappeared for no discernable reason. weird.
EDIT: ...and then they reappeared. wth?