Programming Forums > Application Development > C

DaWei · Apr 12th, 2006, 8:30 AM

Maybe Backdoor Bubba should just make a raid to recover filched items

.

grumpy · Apr 12th, 2006, 8:35 AM

Quote:

Originally Posted by nnxion

I thought you once said that undefined behaviour could be even worse, like wiping the hard disk.

Not so much wiped, as rendered unusable. It happened on a MS-DOS box. I did a rather .... ill-conceived ... operation that involved some pointer dereferencing. I was stepping through the program in a debugger, and suddenly the machine started a cold boot cycle. It failed to reboot. It turned out that the boot sector, one of the file allocation tables, and a number of files had been overwritten. A local guru with some low-level tools restored most of the disk in a couple of hours, and I had some backups from not long before, so it wasn't catastrophic.

I would actually describe that as a rather extreme form of program crash though.

Quote:

Originally Posted by nnxion

on That Other Forum you had a nice 'article' about sorts of behaviours, maybe you'd like to put that up in David's Contributor's Corner� as well.

Ah, yes, one of those things on my list of things to do. I also have to do some tidy up on the exceptions article (I promised David I'd do that a while back, and haven't got around to it; I tend to find it easier to motivate myself to write new stuff than to tweak old stuff though). I have those articles backed up somewhere, as well as a couple I was preparing before that other forum went screwy. I might dedicate the second article I put up for David's contributors corner to JC ..... again, with a sense of irony.

DaWei · Apr 12th, 2006, 9:19 AM

Quote:

.... ill-conceived ... operation that involved some pointer dereferencing

I have the teeshirt, too. Writing with uninitialized pointer in a real-mode box with no MMU, trashed the disk cache.

grumpy · Apr 12th, 2006, 9:36 AM

He, he. My pointer was initialised, but the code did some serious molestation.

InfoGeek · Apr 12th, 2006, 10:40 AM

Quote:

Originally Posted by grumpy

(Toggle Plain Text)

   int x = 165;  /* value bigger than can be held in a char */
   char y;
   x = (char)y;    /* loss of precision here */

I think you mean:

(Toggle Plain Text)

y=(char)x

nnxion · Apr 12th, 2006, 1:02 PM

InfoGeek you nitpicker! :p

deanosrs · Apr 12th, 2006, 1:04 PM

Ok I get casting now, thanks.

But I'm coming across more errors with my array of lists - it's behaving really strangely and I have no idea what it's doing if I'm being completely honest!

There should be 3 instructions in the list isa[13], "jr", "beq" and "nor". However, when the function to search the isa table is looking for "nor", it generates the hash key, 13, looks in the list, finds jr as the first opcode, so I call the search list function recursively with list->next. It should then theoretically compare "beq" with "nor", call itself again and finally find "nor" and print out a successful match. If the list for this function is null at any call, it should print a failed match. It compiles fine, but at runtime it just quits when I ask it to look for "nor" in the table.

Here is the search function:

(Toggle Plain Text)

// given an opcode and the relevant list from the isa array, return the expected arguments string
findopcode(instr *list, char opcode[], char args[]) {
	
	if (list == NULL) { printf("opcode not found: %s, %s\n", list->opcode, opcode); return; }
	
	// if string matches first entry return the expected arguments
	if(strcmp(list->opcode, opcode) == 0) {
		printf("opcode found: %s, %s\n", list->opcode, opcode);
		strcpy(args, list->args);
		return;
		
	}
	
	else {
		findopcode(list->next, opcode, args);
	}
	
}

So I did some investigation - if, after the table has been initialised in the main function, I run this code,

(Toggle Plain Text)

instr charlist = isa[13];
	charlist = *charlist.next;
    printf("%s\n", charlist.opcode);

it still prints out "jr", even though the 2nd opcode in the list should surely be "beq". Is this another one of my pointer errors or is the table screwed up somewhere?

For reference, here is the function that adds data to the table:

(Toggle Plain Text)

// inserts a specific instruction into the isa hash table given the isa table, the opcode string, the number of arguments the instruction takes, and its encoding type
insertinstr(instr isa[], char opcode[], char args[], char type, char bin[]) {
	
	// retrieve the hash key from the opcode string
	int key = geninstrkey(opcode);
	
	// expand the list
	isa[key] = *insertinstrlist(&isa[key], opcode, args, type, bin);
	
}

and that calls this function to add to the specific list:

(Toggle Plain Text)

// inserts another entry at the start of a given list of instructions; these lists are held in the isa hash table
instr *insertinstrlist(instr *instrlist, char opcode[], char args[], char type, char bin[]) {

	instr *t = calloc(1, sizeof(instr));
	strcpy(t->opcode, opcode);
	strcpy(t->args, args);
	t->type = type;
	strcpy(t->bin, bin);
	t->next = instrlist;
	return t;
  
}

If anyone can explain what's going on here would be extremely grateful, I don't want to be coming to you guys to sort out every problem I have - I'm getting the hang of pointers and actually wrote some pretty slick code with them yesterday - think I will have the hang of it all if I can just understand what's going on here!

deanosrs · Apr 12th, 2006, 2:16 PM

Wow I'm all of a sudden getting myself very confused. I have a few questions, like why can't I initialise a list like this:

(Toggle Plain Text)

instr listname = NULL;

and why does this cause a segmentation fault?

(Toggle Plain Text)

instr *isa13 = NULL;
	instr isatable[23];
	isatable[13] = *isa13;

DaWei · Apr 12th, 2006, 2:23 PM

Don't dereference (follow) a NULL pointer. That's like following a blank entry in your address book. You'll wind up nowhere at best and in a hatchet fight at worst. I've lost track of where your code is. Perhaps you'd like to zip it up and attach it.

deanosrs · Apr 12th, 2006, 2:47 PM

code is attached.

I guess at the moment the approach I'm trying to take is to get an array of pointers to the lists - but what confuses me is that a pointer is initialised like this:

int *pointer;

but you can't do this!

int *array[23];

confusoid!

Apr 12th, 2006, 8:30 AM	#21
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Maybe Backdoor Bubba should just make a raid to recover filched items . __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Apr 12th, 2006, 1:02 PM	#26
nnxion Programming Guru Join Date: Jun 2005 Location: elemental plane Posts: 1,429 Rep Power: 5	InfoGeek you nitpicker! :p __________________ "Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." -- Socrates

Apr 12th, 2006, 1:04 PM	#27
deanosrs Programmer Join Date: Apr 2006 Location: Bristol, UK Posts: 31 Rep Power: 0	Ok I get casting now, thanks. But I'm coming across more errors with my array of lists - it's behaving really strangely and I have no idea what it's doing if I'm being completely honest! There should be 3 instructions in the list isa[13], "jr", "beq" and "nor". However, when the function to search the isa table is looking for "nor", it generates the hash key, 13, looks in the list, finds jr as the first opcode, so I call the search list function recursively with list->next. It should then theoretically compare "beq" with "nor", call itself again and finally find "nor" and print out a successful match. If the list for this function is null at any call, it should print a failed match. It compiles fine, but at runtime it just quits when I ask it to look for "nor" in the table. Here is the search function: (Toggle Plain Text) // given an opcode and the relevant list from the isa array, return the expected arguments string findopcode(instr list, char opcode[], char args[]) { if (list == NULL) { printf("opcode not found: %s, %s\n", list->opcode, opcode); return; } // if string matches first entry return the expected arguments if(strcmp(list->opcode, opcode) == 0) { printf("opcode found: %s, %s\n", list->opcode, opcode); strcpy(args, list->args); return; } else { findopcode(list->next, opcode, args); } } // given an opcode and the relevant list from the isa array, return the expected arguments string findopcode(instr list, char opcode[], char args[]) { if (list == NULL) { printf("opcode not found: %s, %s\n", list->opcode, opcode); return; } // if string matches first entry return the expected arguments if(strcmp(list->opcode, opcode) == 0) { printf("opcode found: %s, %s\n", list->opcode, opcode); strcpy(args, list->args); return; } else { findopcode(list->next, opcode, args); } } So I did some investigation - if, after the table has been initialised in the main function, I run this code, (Toggle Plain Text) instr charlist = isa[13]; charlist = charlist.next; printf("%s\n", charlist.opcode); instr charlist = isa[13]; charlist = charlist.next; printf("%s\n", charlist.opcode); it still prints out "jr", even though the 2nd opcode in the list should surely be "beq". Is this another one of my pointer errors or is the table screwed up somewhere? For reference, here is the function that adds data to the table: (Toggle Plain Text) // inserts a specific instruction into the isa hash table given the isa table, the opcode string, the number of arguments the instruction takes, and its encoding type insertinstr(instr isa[], char opcode[], char args[], char type, char bin[]) { // retrieve the hash key from the opcode string int key = geninstrkey(opcode); // expand the list isa[key] = insertinstrlist(&isa[key], opcode, args, type, bin); } // inserts a specific instruction into the isa hash table given the isa table, the opcode string, the number of arguments the instruction takes, and its encoding type insertinstr(instr isa[], char opcode[], char args[], char type, char bin[]) { // retrieve the hash key from the opcode string int key = geninstrkey(opcode); // expand the list isa[key] = insertinstrlist(&isa[key], opcode, args, type, bin); } and that calls this function to add to the specific list: (Toggle Plain Text) // inserts another entry at the start of a given list of instructions; these lists are held in the isa hash table instr insertinstrlist(instr instrlist, char opcode[], char args[], char type, char bin[]) { instr t = calloc(1, sizeof(instr)); strcpy(t->opcode, opcode); strcpy(t->args, args); t->type = type; strcpy(t->bin, bin); t->next = instrlist; return t; } // inserts another entry at the start of a given list of instructions; these lists are held in the isa hash table instr insertinstrlist(instr instrlist, char opcode[], char args[], char type, char bin[]) { instr t = calloc(1, sizeof(instr)); strcpy(t->opcode, opcode); strcpy(t->args, args); t->type = type; strcpy(t->bin, bin); t->next = instrlist; return t; } If anyone can explain what's going on here would be extremely grateful, I don't want to be coming to you guys to sort out every problem I have - I'm getting the hang of pointers and actually wrote some pretty slick code with them yesterday - think I will have the hang of it all if I can just understand what's going on here!

Apr 12th, 2006, 2:16 PM	#28
deanosrs Programmer Join Date: Apr 2006 Location: Bristol, UK Posts: 31 Rep Power: 0	Wow I'm all of a sudden getting myself very confused. I have a few questions, like why can't I initialise a list like this: (Toggle Plain Text) instr listname = NULL; instr listname = NULL; and why does this cause a segmentation fault? (Toggle Plain Text) instr isa13 = NULL; instr isatable[23]; isatable[13] = isa13; instr isa13 = NULL; instr isatable[23]; isatable[13] = isa13;

Apr 12th, 2006, 2:23 PM	#29
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Don't dereference (follow) a NULL pointer. That's like following a blank entry in your address book. You'll wind up nowhere at best and in a hatchet fight at worst. I've lost track of where your code is. Perhaps you'd like to zip it up and attach it. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Apr 12th, 2006, 9:36 AM	#24
grumpy Programming Guru Join Date: Jun 2005 Location: Adelaide, South Australia Posts: 1,260 Rep Power: 5	He, he. My pointer was initialised, but the code did some serious molestation.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Programming Forums > Application Development > C

Assigning an array of lists