LINUX.ORG.RU

bits/confname.h - зачем и как?


0

1

Фрагмент кода из bits/confname.h

/* Values for the NAME argument to `pathconf' and `fpathconf'.  */
enum
  {
    _PC_LINK_MAX,
#define	_PC_LINK_MAX			_PC_LINK_MAX
    _PC_MAX_CANON,
#define	_PC_MAX_CANON			_PC_MAX_CANON
    _PC_MAX_INPUT,
#define	_PC_MAX_INPUT			_PC_MAX_INPUT
    _PC_NAME_MAX,
#define	_PC_NAME_MAX			_PC_NAME_MAX
    _PC_PATH_MAX,
#define	_PC_PATH_MAX			_PC_PATH_MAX
    _PC_PIPE_BUF,
#define	_PC_PIPE_BUF			_PC_PIPE_BUF
    _PC_CHOWN_RESTRICTED,
#define	_PC_CHOWN_RESTRICTED		_PC_CHOWN_RESTRICTED

Зачем? В чём скрытый смысл?

И самое интересное, каким образом это должен понять препроцессор?

Ладно, допустим, это такой хитрый трюк. Но как тогда быть с рекурсивным раскрытием таких конструкций? Приведу пример:

#define A   "This is A"
#define B A
#define C B
#define D C

puts(D);

Т.е. при обработке исходника препроцессором код выродится в puts(«This is A»); Но при препроцессинге bits/confname.h перечисление ещё не определено. И что происходит в такой ситуации?

★★★

Последнее исправление: alman (всего исправлений: 1)

enum {
    A, B
#define A A
};

#ifdef A
#warning Warning
#endif
enum {
    A, B
};

#ifdef A
#warning Warning
#endif

В первом случае будет Warning

anonymous
()

Но при препроцессинге bits/confname.h перечисление ещё не определено

Препроцессору вообще похрен, валидный ли он препроцессит си, и си ли там вообще ;) Внезапно?

Эти дефайны не более чем no-op как макросы, но с тем побочным эффектом, что можно использовать #ifdef _PC_LINK_MAX и т.п.

arturpub ★★
()

А вообще это не более, чем дурацкий способ написать #define _PC_LINK_MAX_DEFINED, и проверять ее в ifdef'ах. Возможно имело место какое-то метапрограммирование на препроцессоре, и, чтобы с именами лишнего не мутить, дефайны поименовали одинаково со значениями.

arturpub ★★
()
Ответ на: комментарий от arturpub

Спасибо. Приятно слышать, что не один я считаю, что способ дурацкий. В принципе, можно считать что с «проблема» решена. Хотя... руки бы надо отрывать за такой способ, тем более что этот enum (как и другие enum'ы в файле bits/confname.h) никак не именованы, а значит использование обычных #define _PC_LINK_MAX_DEFINED 0 было бы правильным решением

alman ★★★
() автор топика
Ответ на: комментарий от arturpub

Нет и нет.

Первое поле emum равно нулю, если явно не указано значение. Еслм константе _PC_LINK_MAX_DEFINED присвоить любое другое значение, то поломается совместимость.

#if defined (_PC_LINK_MAX_DEFINED ) сработает, даже если значение равно нулю. Игнор будет только для выражения #if _PC_LINK_MAX_DEFINED

alman ★★★
() автор топика
Ответ на: комментарий от alman

#if defined (_PC_LINK_MAX_DEFINED ) сработает, даже если

Точно. То ли я затупил, то ли имел ввиду #if без defined, уже сам не пойму :)

arturpub ★★
()
Ответ на: комментарий от alman

Он не дуратцкий - он удобный. Т.е. я могу прочекать любой флаг препроцессором и после его зафигачить - мне лениво думать что там какие-то другие имена у дефайнов и прочее.

Это всё ваялось в допотопные времена, когда что-то там искать было черезжопным занятием.

Чем твоё решение правильно? Объективно оно такое же, причем хуже - мне похрен что там в этом дефайне, как и любому другому пацану. И ифдефу пофиг. Поэтому для тебя правильно _DEFINED - для васи будет правильней что-то ещё.

В чем заключается твоя придирка мне не ясно.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.