After running some tests, it appears that modifying argc inside send_selector() was a bad idea. Reverting the relevant code, and putting the warning back, with some extra comments

svn-id: r49231

1 files changed, 7 insertions, 4 deletions

diff --git a/engines/sci/engine/vm.cpp b/engines/sci/engine/vm.cpp
index 1795b86c85..28e7484098 100644
--- a/engines/sci/engine/vm.cpp
+++ b/engines/sci/engine/vm.cpp
@@ -397,10 +397,6 @@ ExecStack *send_selector(EngineState *s, reg_t send_obj, reg_t work_obj, StackPt
 				printf("Varselector: Read\n");
 #endif // VM_DEBUG_SEND
 
-			// Make sure that argc is either 0 (read) or 1 (write) here.
-			// This isn't strictly necessary, but better safe than sorry
-			argc = MIN<int>(argc, 1);
-
 			// argc == 0: read selector
 			// argc != 0: write selector
 			if (printSendActions && !argc) {	// read selector
@@ -415,6 +411,13 @@ ExecStack *send_selector(EngineState *s, reg_t send_obj, reg_t work_obj, StackPt
 				printSendActions = false;
 			}
 
+			if (argc > 1)
+				// argc can indeed be bigger than 1 in some cases, and it seems correct
+				// (i.e. we should skip that many bytes later on)... question is, why
+				// does this occur? Could such calls be used to point to data after X bytes in the heap?
+				// What are the skipped bytes in this case?
+				warning("send_selector(): more than 1 parameter (%d) while modifying a variable selector", argc);
+
 			{
 				CallsStruct call;
 				call.address.var = varp; // register the call