Data type declaration bug on the LabWindows CVI platform.

LabWindows data type bug.c

int timerHandle = 0;
char statusStr[STATUS_MAX_MSG_CHARS];
double servoDuty[3] = {0.98, 2.102, 7.984};


int CVICALLBACK ServoAutoCalibrate (int panel, int control, int event, void *callbackData, int eventData1, int eventData2)
{
	int position;
	int timerInterval, timerState;
	
	switch (event)
	{
		case EVENT_COMMIT:

			// look up which aperture is being cal'd
			GetCtrlVal(panel, PANEL_POSITION, &position);

			GetAsyncTimerAttribute(timerHandle, ASYNC_ATTR_INTERVAL, &timerInterval);
			
			for (int k=0; k < CAL_AVERAGE_SIZE * timerInterval; k++)
			{					
				GetAsyncTimerAttribute(timerHandle, ASYNC_ATTR_ENABLED, &timerState);
				
				if (timerState == OFF)
					break;
				
				// delay a bit more than the timer period
				DelayWithEventProcessing(timerInterval * 1.01);
			}
		
			sprintf(statusStr, "Old value = %1.3f pwm", servoDuty[position]);
			
			MessagePopup("Status", statusStr);
			break;
	}
	
	return 0;
}

I ran into a code bug that took a while to figure out and I thought I'd pass along the story to warn others.

The following pseudo code contains the bug. The symptom was that mid-execution, the value of position was getting corrupted and thus causing a GPF at the sprintf.

See the bug?

I had mistakenly declared timerInterval as an int, rather than a double. And because I'm not in the habit of error-checking the CVI standard library, the call to GetAsyncTimerAttribute blindly overfilled timerInterval with its double value, which then overwrote the value of position.

position was the collateral damage because it's declared before timerInterval.