Возможно, что + 0 было добавлено для компилятора для выдачи диагностики в случае переопределения функционально-подобных макросов atomic_read и atomic64_read.
Согласно CСтандартно можно переопределить идентификатор, который является функционально-подобным макросом, если второе определение также является функционально-подобным макросом, имеющим одинаковое число и написание параметров, и два списка замены идентичны.
Из стандарта C11 (n1570) раздел 6.10.3 / 2 :
... Аналогично, идентификатор, в настоящее время определяемый как функциональный макрос, не должен быть переопределен другим#define директива предварительной обработки, если только второе определение не является функционально-подобным макроопределением, имеющим одинаковое число и написание параметров, и два списка замены идентичны.
Версия ядра (2.6.26) довольно старый, но аналогичный запрет на такое переопределение можно найти в более старых стандартах до стандарта C89.
В настоящее время макрест atomic_read и atomic64_read определены в файле atomic.h.
Если пользователь переопределит их в некотором исходном файле, как показано ниже:
#define atomic_read(v) (v)->counter
Компилятор выдастдиагностика о переопределении.Это предупреждение выдается, потому что в определении atomic_read из файла atomic.h присутствует + 0.
Если бы не + 0, компилятор не выдал бы диагностику.
Минимальный пример, демонстрирующий эту проблему:
//atomic.h
#define atomic_read(v) ((v)->counter + 0)
#define atomic64_read(v) ((v)->counter)
//some source file that includes atomic.h
#define atomic_read(v) ((v)->counter) //redefinition error
#define atomic64_read(v) ((v)->counter) //no redefinition error
См. Демо