Средства и методы разработки

Если кто-то перепутал байты, то долго можно огребать глупости и выявить только в случае явного выхода за границы проверок. Регрессионный тест по-хорошему должен делаться с заданием параметров у ведомого и сравнением принятого образцовым решением ведущего. В таком случае на этапе дебага при достаточном наборе значений можно проверить отсутствие явных ляпов. 

Вот пример проверки

float currentBalance; /* User's cash balance */ 

void doDeposit() 

{ 

    float val; 

    scanf("%f", &val); 

    if (isinf(val)) 

    { 

        /* Handle infinity error */ 

    } 

    if (isnan(val)) 

    { 

        /* Handle NaN error */ 

    } 

    if (val >= MAX_VALUE - currentBalance) 

    { 

        /* Handle range error */ 

    } 

    currentBalance += val; 

}

и этот пример в принципе оберегает выходное значение, но не охватывает весь диапазон возможной входной чехарды, когда "значения" не попадают в выхлоп проверок. Грубо при наборе определенных значений (типа 0xDEADBEEF:) ), в которых все байты разные в HEX, можно несложно определить некорректность упаковки. Что касается реального диапазона значений для конкретного объекта, то это скорее относится к постановке задачи и стоимости решения. Кто-то проверяет крайние (аварийные) значения, кто-то аварийные и предаварийные, у кого-то есть сигнализация, текущая или триггерная, где-то даже квитирование и журнал, а у кого-то даже обработки таких ошибок не предусмотрено:)

FLP04-C…puts+for+exceptional+values