Косяк у Кейла, Препроцессор не следит за скобками Опции

[ViKo]

Делаю функцию программной задержки. (Длинная не нужна, естественно, но вопрос уже академический, захотел дойти до предела.) Каждый цикл выполняется за 4 такта, отсюда и деление на 4000. Нюансы не интересны, не в этом дело.

Код

#define SYSCLK        48000000ULL
#define _NS    1
#define _US    1000
#define _MS    1000000
#define _SS    1000000000

#define DELAY(VALUE, UNIT);    \
  /* DelayFourCycles(VALUE * UNIT * (SYSCLK / 1000000) / 4000); */ \
  DelayFourCycles((SYSCLK / 1000000) * VALUE * UNIT / 4000);

  DELAY(50, _SS);

Так вот, когда сделал, как в закомментированной строке, Кейл ругается на то, что число не влазит в int. И загружает в функцию абы что. Если же сделать, как в строке без комментария, то все вычисляется правильно. Выходит, Кейл видит что последовательность операций равнозначна, что со скобками, что без, и лихо их отбрасывает. Возникает переполнение. Хотя не понятно, отчего возникает, 64 битов должно хватать (на компьютерном калькуляторе хватает). Как будто у Кейла не 64-битовое вычисление, а меньшее.

[Kabdim]

Огласите пожалуйста решение лучше. Думаю многим было бы интересно на него посмотреть.

[zltigo]

Огласите пожалуйста решение лучше. Думаю многим было бы интересно на него посмотреть.

Давайте все-же по порядку. То, что глупость про "\" написали поняли?

Бессмысленной можно было бы признать запись while(0) {...} - тут warning был бы вполне уместен

Бессмысленнен любой с константой.

в случае do {...} while(0) одна итерация будет выполнена, так что смысл остается (пусть только для помянутой обертки от макроса).

Нет смысла и в этом, ибо для одной итерации достаточно {....}
Так-что весь этот трюк из-за ";" и не для чего более.

там почти все макросы переносом строки,

Да не имеет никкакого отношения склеивание строк к причинам использования этого трюка. ЛЮБОЙ макрос содержащий БОЛЕЕ одного выражения, хоть в одной строке, хоть в 999,
проблематичен при использовании типа такого:
if( )
MACRO();

Посему либо следить за тем, что-бы:
if()
{
MACRO();
}
либо трюк использовать,

Либо только {}, но тогда так
if()
MACRO()

[aaarrr]

Бессмысленнен любой с константой.

Тогда и любимый Вами for(;;) столь же бессмысленнен, т.к. по сути цикл с константой в управляющем выражении.

[zltigo]

Тогда и любимый Вами for(;;) столь же бессмысленнен, т.к. по сути цикл с константой в управляющем выражении.

АБСОЛЮТНО адекватное выражение и по этой причине является официально-страндартым вариантом для бесконечного цикла.
Это есть цикл без проверки условия, а не цикл с проверкой того, что измениться не может.
Неадекватным оно было-бы в виде for( ; 1 ; )

Именно. Управляющее выражение может быть константой (явной или неявной). Все это - while(1) {}, for(;;) {}, do {} while(0) - нормальные и однозначно трактуемые языковые конструкции.

1 и 3 НЕТ. Вменяемые компиляторы выдают warnig именно по причине того, что константное "управляющее выражение" бессмысленно. Отключаемый, но warning.

[aaarrr]

Это есть цикл без проверки условия, а не цикл с проверкой того, что измениться не может.

Да ну! А в стандарте написано, что опущенное управляющее выражение заменяется ненулевой константой:

An omittedexpression-2is replaced by a nonzero constant.

То есть неявно превращается в "цикл с проверкой того, что измениться не может".

[zltigo]

Да ну! А в стандарте написано, что опущенное управляющее выражение заменяется ненулевой константой

Да, это описано ПОВЕДЕНИЕ компилятора. Но когда компилятор видит, что в результате выражения ЕМУ ПЕРЕДАННОГО получается константа, это однозначно тревожный факт указывающий, как минимум на потенциальную ошибку программиста.

[aaarrr]

Да, это описано ПОВЕДЕНИЕ компилятора. Но когда компилятор видит, что в результате выражения ЕМУ ПЕРЕДАННОГО получается константа, это однозначно тревожный факт указывающий, как минимум на потенциальную ошибку программиста.

Это справедливо, например, для такого случая:

Код

unsigned int e;
...
if(e >= 0)
{
}

Тут вменяемые компиляторы дают предупреждение.

Но подозревать потенциальную ошибку в while(0) или while(1) как-то странно.

[zltigo]

Но подозревать потенциальную ошибку в while(0) или while(1) как-то странно.

Ну интеллект компиляторов, конечно растет семимильными шагами и можно многое требовать от них. Но все-же надо прежде всего говорить об ОБЩИХ минимальных требованиях описаных стандартом. А там, даже специально посмотрел C11 - такого требования не было и нет. Кроме того собственно компилятор НЕ знает, что в исходнике написано while( 1 ) - он получает после препроцессора текст, а там могло быть написано и while( EPRST - eklmn() + 1 ) Тут можно уже подозревать ошибку, или?

[aaarrr]

...компилятор НЕ знает, что в исходнике написано while( 1 ) - он получает после препроцессора текст, а там могло быть написано и while( EPRST - eklmn() + 1 ) Тут можно уже подозревать ошибку, или?

Препроцессором можно и черное в белое превратить при желании.