дано:
#define __drv_out(annotes) __post __$drv_group(##__drv_nop(annotes))
макрос используется например из етого места

вопрос:
что сделает первее pp msvc - раскроет макрос __drv_nop или выполнит склеивание?

| Сообщение посчитали полезным:

На сколько мне известно, препроцессор С так до конца и не стандартизировали.
По идее, на мой взгляд (и, похоже, наивным ожиданиям),оно должно тупо подставляться согласно скобкам, т.е. первым должна идти склейка.
С другой стороны, я никогда не был действительным разработчиком, но уже повидал 100500 багов в самых промышленных компиляторах. Компилеры тоже люди пишут, как не крути.

| Сообщение посчитали полезным:

Спасибо за ответ. Со стандартизацией там в порядке.
например и в 9899:1990(5.1.1.2), и в 9899:1999(5.1.1.2) трансляция исходного кода состоит из 8 шагов, где первые 6 касаются исключительно препроцессора. На 7 шаге токены препроцессора превращаются в токены лексического анализатора.
А то что нас касается, выполняется на шаге 4, где происходит раскрытие макросов и выполнение директив препроцессора. На входе который принимает исключительно токены препроцессора(pp-tokens). Определения pp-tokens указаны в главе 6.4


Скорее всего, у pp msvc после склейки ошибка в алгоритме последующих действий.
во - первых, по стандарту полученная строка должна являться pp-token`ом. В реализации строка заново сканируется(проходит шаги трансляции от 1 до 3).
если на выходе после этого не формируется pp-token или формируется больше 1 токена - ошибка.

Вообщем, я прихожу к выводу, что pp msvc не проверяет количество полученных токенов после сканирования склеенной строки.
Практически, данная ошибка встречается в файле windows psdk drvspecs.h

| Сообщение посчитали полезным:

Также есть следующий общеизвестный баг msvc pp.
psdk : WTypes.h

если используется ms компилятор, у которого определено ключевое слово bool, то после макроподстановки _VARIANT_BOOL bool; (Propidl.h, OAidl.h) получается комментарий.

Но если смотреть с точки зрения стандарта, то после склейки мы должны получить pp-token, но `//`
в их число не входит.

| Сообщение посчитали полезным:

Размер типа "bool" так никто и не удосужился стандартизировать. Причем в MS компилере сей тип ведет себя по разному в з0висимости от окружения. Если это С++, то bool - это 1 байт, а если это ANSI-C - то это int (бага/фича компилера? в оригинальном C вобще нет типа bool, хотя все они понимают его без всяких редефайнов)
посему все, кто пробуют использовать данный тип в публичных интерфейсах (а уж тем более в структурах), подвергаются анальной каре, и увольняются нахуй без права голоса.
Это я типа про всякие титан-энжины, на сорцы которых без слез невозможно смотреть.

| Сообщение посчитали полезным:

DrGolova пишет:
бага/фича компилера? в оригинальном C вобще нет типа bool, хотя все они понимают его без всяких редефайнов

ISO/IEC 9899:1999:

1 The header <stdbool.h> defines four macros.
2 The macro
bool
expands to _Bool.

An object declared as type _Bool is large enough to store the values 0 and 1.
The type
_Bool and the unsigned integer types that correspond to the standard signed integer
types are the standard unsigned integer types.

а с размером - плохо

| Сообщение посчитали полезным:

С вашим подходом в стандарте вообще всё плохо, т.к. размер явно не указан ни для одного из базовых типов, есть только ряд ограничений.

| Сообщение посчитали полезным:

cppasm пишет:
размер явно не указан ни для одного из базовых типов

An object declared as type signed char occupies the same amount of storage as a
‘‘plain’’ char object. A ‘‘plain’’ int object has the natural size suggested by the
architecture of the execution environment (large enough to contain any value in the range
INT_MIN to INT_MAX as defined in the header <limits.h>).

сложно сказать

| Сообщение посчитали полезным: