Чи є технічно невизначена поведінка «хакерства»?

Про що я запитую - це добре відомий трюк "останній член структури має змінну довжину". Це щось подібне:

struct T {
    int len;
    char s[1];
};

struct T *p = malloc(sizeof(struct T) + 100);
p->len = 100;
strcpy(p->s, "hello world");

Через те, що структура закладена в пам’яті, ми можемо накладати структуру на більший, ніж потрібно, блок і ставитися до останнього члена так, ніби він більший за 1 charвказаний.

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

PS: Я знаю про підхід C99 до цього, я хотів би, щоб відповіді дотримувалися конкретно версії хитрості, як перераховано вище.

Як говориться в FAQ на C :

Не зрозуміло, чи це легально чи портативно, але це досить популярно.

і:

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

Обгрунтування, що стоїть за бітом "строго відповідності", міститься в розділі J.2 Невизначена поведінка , що входить до списку невизначеної поведінки:

• Підрядник масиву знаходиться поза діапазоном, навіть якщо об’єкт, мабуть, доступний із заданим підрядним індексом (як у виразі lvalue, що a[1][7]дається декларацією int a[4][5]) (6.5.6).

Пункт 8 розділу 6.5.6 Оператори добавок також зазначають, що доступ за межами визначених меж масиву не визначений:

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

Я вважаю, що технічно це невизначена поведінка. Стандарт (імовірно) не звертається до нього безпосередньо, тому він підпадає під "або упущення будь-якого явного визначення поведінки". пункт (§ 4/2 C99, § 3,16 / 2 C89), який говорить, що це не визначена поведінка.

Вище "можливо" залежить від визначення оператора, який підписує масив. Зокрема, він говорить: "Вираз постфікса, за яким слід вираз у квадратних дужках [], - це підписане позначення об'єкта масиву." (C89, §6.3.2.1 / 2).

Ви можете стверджувати, що тут порушується "об’єкт масиву" (оскільки ви підписуєтеся за межами визначеного діапазону об'єкта масиву), і в цьому випадку поведінка (трохи більше) явно невизначена, а не просто невизначена ввічливість нічого, що цілком визначає це.

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

Так, це невизначена поведінка.

Звіт про дефекти мови № 051 дає остаточну відповідь на це питання:

Ідіома, хоча є загальною, не є суворо узгодженою

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_051.html

У документі з обгрунтування С99 Комітет додає:

Дійсність цієї конструкції завжди була сумнівною. У відповідь на один звіт про дефекти Комітет вирішив, що це не визначена поведінка, оскільки масив p-> елементів містить лише один елемент, незалежно від того, чи існує пробіл.

Цей конкретний спосіб робити це не визначено явно в жодному стандарті C, але C99 все ж включає в себе "хакерство" як частину мови. У C99 останній член структури може бути "гнучким членом масиву", оголошеним як char foo[](з будь-яким типом, який ви хочете замість char).

Це не визначена поведінка , незалежно від того, що хтось, чиновник чи інше , говорить, тому що це визначено стандартом. p->s, за винятком випадків, коли використовується як значення, оцінює покажчик, ідентичний (char *)p + offsetof(struct T, s). Зокрема, це дійсний charвказівник усередині об’єкта malloc'd, і за ним відразу 100 (або більше залежних від міркувань вирівнювання) послідовних адрес, які також є дійсними як charоб'єкти всередині виділеного об'єкта. Те, що вказівник було отримано, використовуючи ->замість того, щоб явно додавати зміщення до покажчика, повернутого malloc, переданим char *, не має значення.

Технічно p->s[0]- це єдиний елемент charмасиву всередині структури, наступні декілька елементів (наприклад, p->s[1]наскрізь p->s[3]) - це, ймовірно, байти підкладки всередині структури, які можуть бути пошкоджені, якщо ви виконувати присвоєння структурі в цілому, але не якщо ви просто отримаєте доступ до окремих члени та інші елементи - це додатковий простір у виділеному об’єкті, яким ви вільні користуватися, але вам подобається, якщо ви підкоряєтесь вимогам вирівнювання (і charне має вимог вирівнювання).

Якщо ви стурбовані тим, що можливість перекриття із заповненням байт в структурах можете якої - то чином Invoke носових демонів, ви могли б уникнути цього, замінивши 1в [1]багатозначно , яке гарантує , що немає оббивки в кінці структури. Простий, але марнотратний спосіб зробити це - зробити структуру з однаковими членами, за винятком масиву в кінці, і використовувати s[sizeof struct that_other_struct];для масиву. Тоді p->s[i]чітко визначається як елемент масиву в структурі для i<sizeof struct that_other_structта як об'єкт char за адресою, що знаходиться в кінці структури для i>=sizeof struct that_other_struct.

Редагувати: Насправді, у наведеному вище трюку для отримання потрібного розміру вам може знадобитися також поставити об'єднання, що містить кожен простий тип перед масивом, щоб переконатися, що масив починається з максимального вирівнювання, а не посередині прокладки інших елементів . Знову ж таки, я не вважаю, що щось із цього є необхідним, але я пропоную це для найбільш параноїдальних мовних юристів.

Редагування 2: Перекриття байтами з підкладкою, безумовно, не є проблемою через іншу частину стандарту. C вимагає, що якщо дві структури узгоджуються в початковій підпорядкованості своїх елементів, до загальних початкових елементів можна отримати доступ через вказівник на будь-який тип. Як наслідок, якщо було оголошено структуру, ідентичну, struct Tале з більшим кінцевим масивом, елемент s[0]повинен був би збігатися з елементом s[0]в struct T, і наявність цих додаткових елементів не могла б вплинути або вплинути на доступ до загальних елементів більшої структури за допомогою вказівника на struct T.

Так, це технічно невизначена поведінка.

Зауважте, що існує щонайменше три способи реалізації "struct hack":

(1) Оголошення проміжного масиву розміром 0 (найпопулярніший спосіб у застарілому коді). Це, очевидно, UB, оскільки декларації масиву нульового розміру завжди незаконні в C. Навіть якщо він компілюється, мова не дає гарантій щодо поведінки будь-якого коду, що порушує обмеження.

(2) Оголошення масиву з мінімальним юридичним розміром - 1 (ваш випадок). У цьому випадку будь-які спроби взяти покажчик p->s[0]і використовувати його для арифметики вказівника, що виходить за рамки, p->s[1]є невизначеною поведінкою. Наприклад, реалізація налагодження дозволена для створення спеціального вказівника із вбудованою інформацією про діапазон, який буде ловитись щоразу, коли ви намагаєтесь створити покажчик за його межами p->s[1].

(3) Оголошення масиву, наприклад, "дуже великого" розміру, наприклад 10000. Ідея полягає в тому, що оголошений розмір повинен бути більшим за все, що вам може знадобитися в реальній практиці. Цей метод не містить UB щодо масиву доступу до масиву. Однак на практиці ми, звичайно, завжди будемо виділяти менший об'єм пам'яті (лише стільки, скільки реально потрібно). Я не впевнений у законності цього, тобто мені цікаво, наскільки законним є виділення об’єкту менше пам'яті, ніж оголошений розмір об'єкта (якщо припустити, що ми ніколи не отримуємо доступу до "не виділених" членів).

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

І за «роботу на практиці». Я бачив оптимізатор gcc / g ++, що використовує цю частину стандарту, таким чином генеруючи неправильний код при зустрічі з цим недійсним C.

Якщо компілятор приймає щось подібне

typedef structure {
  int len;
  char dat [];
};

Я думаю, що цілком зрозуміло, що він повинен бути готовим прийняти підписник на 'dat' понад його довжину. З іншого боку, якщо хтось кодує щось на кшталт:

typedef structure {
  int що завгодно;
  char dat [1];
} MY_STRUCT;

а потім пізніше звертається до деякоїструктури-> дат [х]; Я не думаю, що компілятор не бере жодного зобов'язання використовувати адрес-обчислювальний код, який буде працювати з великими значеннями x. Я думаю, якби хтось хотів бути справді безпечним, правильна парадигма була б більше схожа на:

#define LARGEST_DAT_SIZE 0xF000
typedef structure {
  int що завгодно;
  char dat [LARGEST_DAT_SIZE];
} MY_STRUCT;

а потім зробіть балот (sizeof (MYSTRUCT) -LARGEST_DAT_SIZE + бажаний_матриця_ довжина) байтів (маючи на увазі, що якщо бажана_арра__ довжина більша за LARGEST_DAT_SIZE, результати можуть бути невизначені).

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