Apakah "struct hack" secara teknis merupakan perilaku yang tidak terdefinisi?

Apa yang saya tanyakan adalah trik terkenal "anggota terakhir dari struct memiliki panjang variabel". Ini berjalan seperti ini:

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

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

Karena cara struct diletakkan dalam memori, kami dapat melapisi struct di atas blok yang lebih besar dari yang diperlukan dan memperlakukan anggota terakhir seolah-olah lebih besar dari yang 1 charditentukan.

Jadi pertanyaannya adalah: Apakah teknik ini secara teknis merupakan perilaku yang tidak terdefinisi? . Saya berharap begitu, tetapi penasaran apa yang dikatakan standar tentang ini.

PS: Saya mengetahui pendekatan C99 untuk ini, saya ingin jawaban menempel secara khusus pada versi trik seperti yang tercantum di atas.

Seperti yang dikatakan C FAQ :

Tidak jelas apakah itu legal atau portabel, tetapi cukup populer.

dan:

... interpretasi resmi menganggap bahwa ini tidak sepenuhnya sesuai dengan Standar C, meskipun tampaknya berfungsi di bawah semua implementasi yang diketahui. (Kompiler yang memeriksa batas array dengan hati-hati mungkin mengeluarkan peringatan.)

Alasan di balik bit 'yang benar-benar sesuai' ada dalam spesifikasi, bagian J.2 Perilaku tidak terdefinisi, yang mencakup dalam daftar perilaku yang tidak ditentukan:

• Sebuah subskrip array berada di luar jangkauan, bahkan jika sebuah objek tampaknya dapat diakses dengan subskrip yang diberikan (seperti dalam ekspresi lvalue yang a[1][7]diberikan deklarasi int a[4][5]) (6.5.6).

Paragraf 8 dari Bagian 6.5.6 Operator aditif memiliki penyebutan lain bahwa akses di luar batas array yang ditentukan tidak ditentukan:

Jika kedua operan penunjuk dan hasil menunjuk ke elemen dari objek larik yang sama, atau melewati elemen terakhir dari objek larik, evaluasi tidak akan menghasilkan luapan; jika tidak, perilaku tidak terdefinisi.

Saya percaya bahwa secara teknis ini adalah perilaku yang tidak terdefinisi. Standar (bisa dibilang) tidak membahasnya secara langsung, jadi itu termasuk di bawah "atau dengan menghilangkan definisi eksplisit apa pun dari perilaku." klausa (§4 / 2 dari C99, §3.16 / 2 dari C89) yang mengatakan itu perilaku yang tidak ditentukan.

"Bisa dibilang" di atas bergantung pada definisi operator langganan array. Secara khusus, ia mengatakan: "Ekspresi postfix diikuti dengan ekspresi dalam tanda kurung siku [] adalah penunjukan objek array yang disubscripsikan." (C89, §6.3.2.1 / 2).

Anda dapat berargumen bahwa "objek array" sedang dilanggar di sini (karena Anda berlangganan di luar rentang objek array yang ditentukan), dalam hal ini perilakunya (sedikit lebih) secara eksplisit tidak ditentukan, bukan hanya tidak terdefinisi milik tidak ada yang cukup mendefinisikannya.

Secara teori, saya dapat membayangkan kompiler yang melakukan pemeriksaan batas-batas array dan (misalnya) akan membatalkan program ketika / jika Anda mencoba menggunakan subskrip di luar jangkauan. Faktanya, saya tidak tahu tentang hal seperti itu, dan mengingat popularitas gaya kode ini, bahkan jika kompiler mencoba menerapkan langganan dalam beberapa keadaan, sulit untuk membayangkan bahwa ada orang yang tahan melakukannya di situasi ini.

Ya, ini adalah perilaku yang tidak ditentukan.

Laporan Cacat Bahasa C # 051 memberikan jawaban pasti untuk pertanyaan ini:

Ungkapan itu, meski umum, tidak sepenuhnya selaras

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

Dalam dokumen C99 Rationale, C Committee menambahkan:

Validitas konstruksi ini selalu dipertanyakan. Menanggapi satu Laporan Cacat, Komite memutuskan bahwa itu adalah perilaku yang tidak ditentukan karena larik p-> item hanya berisi satu item, terlepas dari apakah ruang tersebut ada.

Cara tertentu untuk melakukannya tidak secara eksplisit didefinisikan dalam standar C mana pun, tetapi C99 menyertakan "struct hack" sebagai bagian dari bahasa. Di C99, anggota terakhir dari sebuah struct dapat berupa "anggota array fleksibel", dideklarasikan sebagai char foo[](dengan tipe apa pun yang Anda inginkan sebagai gantinya char).

Ini bukan perilaku yang tidak terdefinisi , terlepas dari apa yang dikatakan seseorang, resmi atau tidak , karena itu ditentukan oleh standar. p->s, kecuali jika digunakan sebagai nilai l, mengevaluasi ke penunjuk yang identik dengan (char *)p + offsetof(struct T, s). Secara khusus, ini adalah charpenunjuk yang valid di dalam objek malloc'd, dan ada 100 (atau lebih, tergantung pada pertimbangan penyelarasan) alamat berturut-turut segera mengikutinya yang juga valid sebagai charobjek di dalam objek yang dialokasikan. Fakta bahwa pointer diturunkan dengan menggunakan ->bukannya secara eksplisit menambahkan offset ke pointer yang dikembalikan oleh malloc, cast to char *, tidak relevan.

Secara teknis, p->s[0]adalah elemen tunggal dari chararray di dalam struct, beberapa elemen berikutnya (misalnya p->s[1]melalui p->s[3]) kemungkinan besar padding byte di dalam struct, yang dapat rusak jika Anda melakukan penugasan ke struct secara keseluruhan tetapi tidak jika Anda hanya mengakses individu anggota, dan elemen lainnya adalah ruang tambahan dalam objek yang dialokasikan yang dapat Anda gunakan secara bebas sesuka Anda, selama Anda mematuhi persyaratan penyelarasan (dan chartidak memiliki persyaratan penyelarasan).

Jika Anda khawatir bahwa kemungkinan tumpang tindih dengan byte padding di struct mungkin entah bagaimana memanggil setan hidung, Anda dapat menghindari ini dengan mengganti 1in [1]dengan nilai yang memastikan bahwa tidak ada padding di akhir struct. Cara sederhana namun boros untuk melakukan ini adalah dengan membuat struct dengan anggota yang identik kecuali tidak ada larik di akhir, dan digunakan s[sizeof struct that_other_struct];untuk larik. Kemudian, p->s[i]secara jelas didefinisikan sebagai elemen dari array di struct untuk i<sizeof struct that_other_structdan sebagai objek char di alamat setelah akhir dari struct untuk i>=sizeof struct that_other_struct.

Sunting: Sebenarnya, dalam trik di atas untuk mendapatkan ukuran yang tepat, Anda mungkin juga perlu meletakkan gabungan yang berisi setiap tipe sederhana sebelum larik, untuk memastikan bahwa larik itu sendiri dimulai dengan perataan maksimal daripada di tengah padding elemen lain . Sekali lagi, saya tidak percaya semua ini perlu, tapi saya menawarkannya untuk pengacara bahasa paling paranoid di luar sana.

Sunting 2: Tumpang tindih dengan padding byte jelas bukan masalah, karena bagian lain dari standar. C mensyaratkan bahwa jika dua struct setuju dalam urutan awal elemen mereka, elemen awal yang sama dapat diakses melalui penunjuk ke salah satu tipe. Akibatnya, jika sebuah struct identik dengan struct Ttetapi dengan larik akhir yang lebih besar dideklarasikan, elemen s[0]tersebut harus bertepatan dengan elemen s[0]di struct T, dan keberadaan elemen tambahan ini tidak dapat mempengaruhi atau dipengaruhi dengan mengakses elemen umum dari struct yang lebih besar. menggunakan penunjuk ke struct T.

Ya, ini adalah perilaku yang secara teknis tidak ditentukan.

Perhatikan, setidaknya ada tiga cara untuk menerapkan "struct hack":

(1) Mendeklarasikan trailing array dengan ukuran 0 (cara paling "populer" di kode lama). Ini jelas UB, karena deklarasi larik ukuran nol selalu ilegal di C. Bahkan jika dikompilasi, bahasa tersebut tidak menjamin tentang perilaku kode yang melanggar batasan.

(2) Menyatakan array dengan ukuran legal minimal - 1 (kasus Anda). Dalam hal ini setiap upaya untuk mengambil pointer ke p->s[0]dan menggunakannya untuk aritmatika pointer yang melampaui p->s[1]perilaku tidak terdefinisi. Misalnya, implementasi debugging diizinkan untuk menghasilkan pointer khusus dengan informasi rentang yang disematkan, yang akan menjebak setiap kali Anda mencoba membuat pointer di luar p->s[1].

(3) Mendeklarasikan array dengan ukuran "sangat besar" seperti 10000, misalnya. Idenya adalah bahwa ukuran yang dinyatakan seharusnya lebih besar dari apa pun yang mungkin Anda butuhkan dalam praktik aktual. Metode ini gratis di UB terkait dengan jangkauan akses array. Namun, dalam praktiknya, tentunya kita akan selalu mengalokasikan jumlah memori yang lebih kecil (hanya sebanyak yang benar-benar dibutuhkan). Saya tidak yakin tentang legalitas ini, yaitu saya bertanya-tanya seberapa legal mengalokasikan lebih sedikit memori untuk objek daripada ukuran objek yang dinyatakan (dengan asumsi kita tidak pernah mengakses anggota "non-dialokasikan").

Standar cukup jelas bahwa Anda tidak dapat mengakses hal-hal di samping akhir larik. (dan melalui pointer tidak membantu, karena Anda tidak diizinkan untuk menambah bahkan pointer melewati satu setelah akhir array).

Dan untuk "bekerja dalam praktek". Saya telah melihat pengoptimal gcc / g ++ menggunakan bagian standar ini sehingga menghasilkan kode yang salah saat memenuhi C yang tidak valid ini.

Jika kompiler menerima sesuatu seperti

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

Saya pikir cukup jelas bahwa itu harus siap menerima subskrip pada 'dat' di luar panjangnya. Di sisi lain, jika seseorang membuat kode seperti:

typedef struct {
  int apapun;
  char dat [1];
} MY_STRUCT;

dan kemudian mengakses somestruct-> dat [x]; Saya tidak akan berpikir compiler berkewajiban untuk menggunakan kode alamat-komputasi yang akan bekerja dengan nilai x yang besar. Saya pikir jika seseorang ingin benar-benar aman, paradigma yang tepat akan lebih seperti:

#tentukan LARGEST_DAT_SIZE 0xF000
typedef struct {
  int apapun;
  char dat [LARGEST_DAT_SIZE];
} MY_STRUCT;

dan kemudian lakukan malloc sebesar (sizeof (MYSTRUCT) -LARGEST_DAT_SIZE + dikehendaki_array_length) byte (ingat bahwa jika diinginkan_array_length lebih besar dari LARGEST_DAT_SIZE, hasilnya mungkin tidak ditentukan).

Kebetulan, saya pikir keputusan untuk melarang array dengan panjang nol adalah keputusan yang tidak menguntungkan (beberapa dialek lama seperti Turbo C mendukungnya) karena array dengan panjang nol dapat dianggap sebagai tanda bahwa kompiler harus menghasilkan kode yang akan bekerja dengan indeks yang lebih besar .