Перевизначення NULL

Я пишу код C для системи, де адреса 0x0000 є дійсною і містить порт вводу / виводу. Тому будь-які можливі помилки, які отримують доступ до вказівника NULL, залишаться невиявленими та водночас спричинятимуть небезпечну поведінку.

З цієї причини я хочу змінити NULL як іншу адресу, наприклад, адресу, що не відповідає дійсності. Якщо я випадково отримав доступ до такої адреси, я отримаю апаратне переривання, де я можу виправити помилку. У мене, можливо, є доступ до stddef.h для цього компілятора, тому я фактично можу змінити стандартний заголовок і переглянути нову NULL.

Моє запитання: чи буде це конфліктом зі стандартом С? Наскільки я можу сказати з 7,17 у стандарті, макрос визначений реалізацією. Чи є ще щось у стандарті, що говорить про те, що NULL має бути 0?

Інша проблема полягає в тому, що велика кількість компіляторів здійснює статичну ініціалізацію, встановлюючи все на нуль, незалежно від типу даних. Навіть незважаючи на те, що стандарт говорить, що компілятор повинен встановити цілі числа на нуль, а покажчики на NULL. Якщо я міг би визначити NULL для свого компілятора, то я знаю, що така статична ініціалізація вийде з ладу. Чи можу я вважати це неправильним поведінкою компілятора, хоча я сміливо змінював заголовки компілятора вручну? Тому що я точно знаю, що саме цей компілятор не отримує доступу до макросу NULL, коли робить статичну ініціалізацію.

Стандарт C не вимагає, щоб нульові вказівники знаходилися на нулі адреси машини. ЯКЩО введення 0константи до значення вказівника повинно призвести до NULLпокажчика (§6.3.2.3 / 3), а оцінка нульового вказівника як булевого має бути помилковою. Це може бути трохи незручно , якщо ви дійсно зробити хочете нульовий адресу, а NULLне нульовий адресу.

Тим не менш, з (важкими) модифікаціями компілятора та стандартної бібліотеки, це не неможливо NULLбути представленим альтернативним бітовим малюнком, залишаючись при цьому строго відповідним стандартній бібліотеці. Це НЕ досить просто змінити визначення NULLсаме по собі , однак, як і тоді NULLбуде обчислюватися так.

Зокрема, вам потрібно буде:

• Впорядковуйте для прямої нулі в призначеннях покажчики (або касти до покажчиків), які слід перетворити на якесь інше магічне значення, наприклад -1.
• Упорядкуйте тести рівності між покажчиками та постійним цілим числом, 0щоб перевірити, чи не магічне значення замість цього (§6.5.9 / 6)
• Упорядкуйте для всіх контекстів, у яких тип вказівника оцінюється як булевий, щоб перевірити рівність магічному значенню, а не перевірку нуля. Це випливає із семантики тестування рівності, але компілятор може реалізувати її по-різному всередині. Див. §6.5.13 / 3, §6.5.14 / 3, §6.5.15 / 4, §6.5.3.3 / 5, §6.8.4.1 / 2, §6.8.5 / 4
• Як зазначає кафе, оновіть семантику для ініціалізації статичних об'єктів (§ 6.7.8 / 10) та часткових складових ініціалізаторів (§ 6.7.8 / 21), щоб відобразити нове представлення нульових покажчиків.
• Створіть альтернативний спосіб отримати доступ до справжньої нульової адреси.

Є деякі речі, з якими не треба впоратися. Наприклад:

int x = 0;
void *p = (void*)x;

Після цього pНЕ гарантовано є нульовим покажчиком. Потрібно обробляти лише постійні призначення (це хороший підхід для доступу до істинної нульової адреси). Аналогічно:

int x = 0;
assert(x == (void*)0); // CAN BE FALSE

Також:

void *p = NULL;
int x = (int)p;

xне гарантовано буде 0.

Коротше кажучи, ця сама умова, очевидно, була розглянута Комітетом з мов C, а також розглядалися питання щодо тих, хто обирає альтернативне представництво для NULL. Все, що вам потрібно зробити зараз, - це зробити значні зміни у вашому компіляторі, і ей престо, що ви зробили :)

Як бічна примітка, ці зміни можуть бути здійснені на етапі трансформації вихідного коду до відповідного компілятора. Тобто замість нормального потоку препроцесора -> компілятора -> асемблера -> лінкера, ви додасте препроцесор -> перетворення NULL -> компілятор -> асемблер -> посилання. Тоді ви можете зробити перетворення на зразок:

p = 0;
if (p) { ... }
/* becomes */
p = (void*)-1;
if ((void*)(p) != (void*)(-1)) { ... }

Для цього знадобиться повний синтаксичний аналізатор, а також аналізатор типу та аналіз typedefs та змінних оголошень, щоб визначити, які ідентифікатори відповідають покажчикам. Однак, зробивши це, можна уникнути необхідності внесення змін до частин генерації коду компілятора. Кланг може бути корисним для здійснення цього - я розумію, що він був розроблений на зразок таких перетворень. Вам, ймовірно, знадобиться внести зміни до стандартної бібліотеки.

Стандарт стверджує, що ціле постійне вираз зі значенням 0 або такий вираз, перетворений у void *тип, є нульовою постійною покажчиком. Це означає, що (void *)0завжди є нульовим покажчиком, але дано int i = 0;, (void *)iбути не повинно.

Реалізація C складається з компілятора разом із його заголовками. Якщо ви модифікуєте заголовки для повторного визначення NULL, але не змінюєте компілятор, щоб виправити статичні ініціалізації, тоді ви створили невідповідну реалізацію. Це вся реалізація, взята разом, має неправильну поведінку, і якщо ви порушили її, ви насправді нікому більше не винні;)

Ви повинні виправити більше, ніж просто статичні ініціалізації, звичайно - якщо вказати вказівник p, if (p)еквівалентно if (p != NULL), завдяки вищезазначеному правилу.

Якщо ви використовуєте бібліотеку C std, у вас виникнуть проблеми з функціями, які можуть повернути NULL. Наприклад, документація malloc зазначає:

Якщо функція не змогла виділити запитуваний блок пам'яті, повертається нульовий покажчик.

Оскільки функції malloc та пов'язані з ними функції вже складені у бінарні файли з певним значенням NULL, якщо ви повторно визначите NULL, ви не зможете безпосередньо використовувати бібліотеку C std, якщо не зможете відновити весь інструментальний ланцюг, включаючи C std lib.

Також через використання NULL бібліотекою std, якщо ви повторно визначите NULL перед включенням заголовків std, ви можете перезаписати визначення NULL, вказане в заголовках. Все, що вкладено, було б невідповідним для складених об'єктів.

Я б замість цього визначив ваш власний NULL, "MYPRODUCT_NULL", для власних цілей використання, або уникати або перекладати з / в бібліотеку C std.

Залиште NULL у спокої і обробіть IO до порту 0x0000 як особливий випадок, можливо, використовуючи рутинну програму, написану в ассемблері, і, таким чином, не підпадаючи під стандартну семантику C. IOW, не переосмислюйте NULL, перегляньте порт 0x00000.

Зауважте, що якщо ви пишете чи змінюєте компілятор C, робота, необхідна для уникнення перенаправлення NULL (якщо припустити, що у вашому випадку процесор не допомагає), є однаковою незалежно від того, як визначено NULL, тому простіше залишити NULL визначеним як нуль, і переконайтесь, що нуль ніколи не може бути відмінений від C.

Враховуючи надзвичайну складність у переосмисленні NULL, про яку згадували інші, можливо, легше переосмислити перенаправлення для відомих апаратних адрес. Створюючи адресу, додайте 1 до кожної відомої адреси, щоб ваш відомий порт IO був:

  #define CREATE_HW_ADDR(x)(x+1)
  #define DEREFERENCE_HW_ADDR(x)(*(x-1))

  int* wellKnownIoPort = CREATE_HW_ADDR(0x00000000);

  printf("IoPortIs" DEREFERENCE_HW_ADDR(wellKnownIoPort));

Якщо адреси, які вас цікавлять, згруповані разом, і ви можете бути впевнені, що додавання 1 до адреси не буде конфліктувати ні з чим (що не повинно в більшості випадків), ви можете це зробити безпечно. І тоді вам не потрібно буде турбуватися про перебудову ланцюжка інструментів / std lib та виразів у формі:

  if (pointer)
  {
     ...
  }

досі працює

Божевільний я знаю, але просто думав, що викину ідею туди :).

Шаблон біта для нульового вказівника може бути не такий, як бітовий шаблон для цілого числа 0. Але розширення макросу NULL повинно бути константою нульового вказівника, тобто постійним цілим числом значення 0, яке може бути закинуто (недійсним) *).

Щоб досягти результату, який ви хочете, зберігаючи відповідність, вам доведеться змінити (або, можливо, налаштувати) ланцюжок інструментів, але це досяжно.

Ти просиш клопоту. Повторне NULLвизначення ненульового значення порушить цей код:

   якщо (myPointer)
   {
      // myPointer не є нульовим
      ...
   }