Опасные определения, приводят к катастрофе! Опции

[ivainc1789]

В программе есть описания:

#define BIT(x) (1 << (x))
#define SETBIT(x,y) (x |= (1<<y)) // Set bit y in byte x
#define SETBITS(x,y) (x |= (y)) // Set bits y in byte x

Соответственно при написании исходных текстов пользователь может забыть как правильно использовать эти определения и написать примерно так:

SETBIT(TIMSK,TOIE1);
SETBITS(TIMSK,TOIE1+TOIE0);

Очевидно, оба предложения валидны с точки зрения компилятора при использовании стандартных определений битов (через цифры 7...0). Однако второе предложение является ошибочным. Нужно правильно записать так:

SETBITS(TIMSK,BIT(TOIE1)+BIT(TOIE0));

Хотелось бы сделать так, чтобы либо компилятор выдавал сообщение об ошибке, или переписать определение для SETBITS, чтобы оно имело бОльшую "защиту от дурака".
Как это разумнее сделать в IAR EWAVR?

[singlskv]

В программе есть описания:

#define BIT(x) (1 << (x))
#define SETBIT(x,y) (x |= (1<<y)) // Set bit y in byte x
#define SETBITS(x,y) (x |= (y)) // Set bits y in byte x

Соответственно при написании исходных текстов пользователь может забыть как правильно использовать эти определения и написать примерно так:

SETBIT(TIMSK,TOIE1);
SETBITS(TIMSK,TOIE1+TOIE0);

Я обычно делаю так
#define TOIE1_MASK (1<<TOIE1)
#define TOIE0_MASK (1<<TOIE0)
#define TOIE01_MASK (TOIE1_MASK | TOIE1_MASK)

Если лень писать каждый раз _MASK то заменяем его на _M, типа TOIE1_M, ну или как-то еще,
удобнее автору.

количество вариантов значений которые нужно пинать в регистр обычно ограничено 2-3
по этому можно писать и так:
#define TIMSK_M1 (1<<TOIE1)
#define TIMSK_M2 ((1<<TOIE1) | (1<<TOIE0))

ну и применение
TIMSK |= TIMSK_Mx;

Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement

Скобочки где-то забыли, например при 1<<yy
у << маленький приоритет

[zltigo]

у << маленький приоритет

Скобочки, действительно, абсолютно обязательны, но вот приоритет у поразрядных сдвигов самый высокий среди упомяутых выше операций, и даже разворот в такое мутное выражение
TIMSK |= 1<<2 | 1<<4;
дает вполне однозначный результат.

[singlskv]

Скобочки, действительно, абсолютно обязательны, но вот приоритет у поразрядных сдвигов самый высокий среди упомяутых выше операций, и даже разворот в такое мутное выражение
TIMSK |= 1<<2 | 1<<4;
дает вполне однозначный результат.

Ну конечно Вы правы...
за исключением одного момента,
афтар почему-то в первоначальном посте указал нам что он предпочитает
использовать BIT(TOIE1)+BIT(TOIE0) вместо BIT(TOIE1)|BIT(TOIE0),
а у них уже разный приоритет относительно барикады (<<)

[zltigo]

а у них уже разный приоритет относительно барикады (<<)

Тогда вилы .
Хотя вообще '+' использовать последнее дело - при перекрытии битов, получить эффектов по полной программе можно. А оно это надо?

[singlskv]

Тогда вилы .

Поэтому и предлагаю сформулировать правило:
1<<XX ВСЕГДА ПИШИ В СКОБКАХ
сам пользуюсь и другим желаю, не пожалеете...

[zltigo]

Поэтому и предлагаю сформулировать правило:
1<<XX ВСЕГДА ПИШИ В СКОБКАХ

Все строже - в макросах абсолютно все выражения и все аргументы всегда в скобках. Без вариантов!
Пример:
#define func( a, x ) ((a)+((x)<<2))

[singlskv]

Все строже - в макросах абсолютно все выражения и все аргументы всегда в скобках. Без вариантов!
Пример:
#define func( a, x ) ((a)+((x)<<2))

+1
В макросах - без вариантов

1<<XX ВСЕГДА ПИШИ В СКОБКАХ
во всех вариантах без разбору,
очень помагает для сохранения нервной системы

[zltigo]

1<<XX ВСЕГДА ПИШИ В СКОБКАХ
во всех вариантах без разбору,
очень помагает для сохранения нервной системы

Ну это Вы похоже как-то на грабли больно наступили . Почему (1<<XX) "всегда" а например,
1 & XX
"не всегда"? Хотя второе много опаснее ввиду более низкого приоритета, не говоря уже о
1 | XX
или страшно сказать
XX |= 1
В общем думать надо всегда, ну и скобочки не жалеть, но ровно в меру! тоже не помешает для читабельности.