C / C ++: บังคับลำดับฟิลด์บิตและการจัดตำแหน่ง

ฉันอ่านว่าลำดับของเขตข้อมูลบิตภายในโครงสร้างเป็นแพลตฟอร์มเฉพาะ แล้วถ้าฉันใช้ตัวเลือกการบรรจุเฉพาะของคอมไพเลอร์ที่แตกต่างกันข้อมูลการรับประกันนี้จะถูกจัดเก็บตามลำดับที่ถูกต้องตามที่เขียนหรือไม่ ตัวอย่างเช่น:

struct Message
{
  unsigned int version : 3;
  unsigned int type : 1;
  unsigned int id : 5;
  unsigned int data : 6;
} __attribute__ ((__packed__));

บนโปรเซสเซอร์ Intel ที่มีคอมไพเลอร์ GCC ฟิลด์ต่างๆจะถูกจัดวางไว้ในหน่วยความจำตามที่แสดง Message.versionเป็น 3 บิตแรกในบัฟเฟอร์และMessage.typeตามด้วย หากฉันพบตัวเลือกการบรรจุโครงสร้างที่เทียบเท่ากันสำหรับคอมไพเลอร์ต่างๆสิ่งนี้จะเป็นข้ามแพลตฟอร์มหรือไม่

ไม่มันจะไม่สามารถพกพาได้อย่างเต็มที่ ตัวเลือกการบรรจุสำหรับโครงสร้างเป็นส่วนขยายและไม่สามารถพกพาได้อย่างเต็มที่ นอกจากนั้น C99 §6.7.2.1ย่อหน้าที่ 10 ยังกล่าวว่า: "ลำดับของการจัดสรรบิตฟิลด์ภายในหน่วย

แม้แต่คอมไพลเลอร์ตัวเดียวก็อาจจัดวางฟิลด์บิตแตกต่างกันไปขึ้นอยู่กับความสิ้นสุดของแพลตฟอร์มเป้าหมายตัวอย่างเช่น

ช่องบิตแตกต่างกันอย่างมากในแต่ละคอมไพเลอร์ถึงคอมไพเลอร์ขออภัย

ด้วย GCC เครื่องจักร endian ขนาดใหญ่จะวางบิตที่ใหญ่ที่สุดเครื่องแรกและ endian เล็ก ๆ น้อย ๆ จะวางส่วนท้ายเล็กน้อยก่อน

K&R กล่าวว่า "สมาชิกฟิลด์ที่อยู่ติดกัน [บิต -] ของโครงสร้างจะถูกบรรจุลงในหน่วยเก็บข้อมูลที่ขึ้นอยู่กับการนำไปใช้งานในทิศทางที่ขึ้นอยู่กับการนำไปใช้งานเมื่อฟิลด์ที่ตามหลังฟิลด์อื่นจะไม่พอดี ... อาจถูกแบ่งระหว่างหน่วย ช่องว่างที่ไม่มีชื่อความกว้าง 0 บังคับให้ช่องว่างนี้ ... "

ดังนั้นหากคุณต้องการเลย์เอาต์ไบนารีอิสระของเครื่องจักรคุณต้องทำด้วยตัวเอง

คำสั่งสุดท้ายนี้ยังใช้กับฟิลด์ที่ไม่ใช่บิตเนื่องจากการขยาย - อย่างไรก็ตามคอมไพเลอร์ทั้งหมดดูเหมือนจะมีวิธีบังคับให้บรรจุไบต์ของโครงสร้างตามที่ฉันเห็นคุณได้ค้นพบแล้วสำหรับ GCC

ควรหลีกเลี่ยง Bitfields - ไม่สามารถพกพาได้ระหว่างคอมไพเลอร์แม้จะใช้กับแพลตฟอร์มเดียวกันก็ตาม จากมาตรฐาน C99 6.7.2.1/10 - "โครงสร้างและตัวระบุสหภาพ" (มีถ้อยคำที่คล้ายกันในมาตรฐาน C90):

การใช้งานอาจจัดสรรหน่วยเก็บข้อมูลแอดเดรสใด ๆ ให้ใหญ่พอที่จะเก็บบิตฟิลด์ หากมีพื้นที่เหลือเพียงพอบิตฟิลด์ที่ตามหลังบิตฟิลด์อื่นในโครงสร้างทันทีจะถูกบรรจุลงในบิตที่อยู่ติดกันของหน่วยเดียวกัน หากยังคงมีพื้นที่ไม่เพียงพอไม่ว่าจะใส่บิตฟิลด์ที่ไม่พอดีลงในหน่วยถัดไปหรือทับซ้อนกับหน่วยที่อยู่ติดกันจะถูกกำหนดให้ใช้งาน ลำดับของการจัดสรรบิตฟิลด์ภายในหน่วย (ลำดับสูงไปยังลำดับต่ำหรือลำดับต่ำไปยังลำดับสูง) ได้รับการกำหนดการใช้งาน การจัดตำแหน่งของหน่วยจัดเก็บแอดเดรสไม่ได้ระบุไว้

คุณไม่สามารถรับประกันได้ว่าฟิลด์บิตจะ 'ขยาย' ขอบเขต int หรือไม่และคุณไม่สามารถระบุได้ว่าบิตฟิลด์เริ่มต้นที่ระดับต่ำสุดของ int หรือระดับไฮเอนด์ของ int (ไม่ขึ้นอยู่กับว่าโปรเซสเซอร์เป็น big-endian หรือ little-endian)

ชอบ bitmasks ใช้อินไลน์ (หรือแม้แต่มาโคร) เพื่อตั้งค่าล้างและทดสอบบิต

endianness กำลังพูดถึงคำสั่งไบต์ไม่ใช่คำสั่งบิต ทุกวันนี้มั่นใจได้ 99% ว่าคำสั่งบิตได้รับการแก้ไขแล้ว อย่างไรก็ตามเมื่อใช้ bitfields ควรนับ endianness ดูตัวอย่างด้านล่าง

#include <stdio.h>

typedef struct tagT{

    int a:4;
    int b:4;
    int c:8;
    int d:16;
}T;


int main()
{
    char data[]={0x12,0x34,0x56,0x78};
    T *t = (T*)data;
    printf("a =0x%x\n" ,t->a);
    printf("b =0x%x\n" ,t->b);
    printf("c =0x%x\n" ,t->c);
    printf("d =0x%x\n" ,t->d);

    return 0;
}

//- big endian :  mips24k-linux-gcc (GCC) 4.2.3 - big endian
a =0x1
b =0x2
c =0x34
d =0x5678
 1   2   3   4   5   6   7   8
\_/ \_/ \_____/ \_____________/
 a   b     c           d

// - little endian : gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
a =0x2
b =0x1
c =0x34
d =0x7856
 7   8   5   6   3   4   1   2
\_____________/ \_____/ \_/ \_/
       d           c     b   a

ส่วนใหญ่แล้วอาจเป็นได้ แต่อย่าเดิมพันฟาร์มเพราะถ้าคุณผิดคุณจะสูญเสียก้อนโต

หากคุณจำเป็นต้องมีข้อมูลไบนารีที่เหมือนกันจริงๆคุณจะต้องสร้าง bitfields ด้วย bitmasks เช่นคุณใช้ข้อความสั้นที่ไม่ได้ลงชื่อ (16 บิต) สำหรับข้อความจากนั้นสร้างสิ่งต่างๆเช่น versionMask = 0xE000 เพื่อแทนบิตสูงสุดสาม

มีปัญหาคล้ายกันกับการจัดตำแหน่งภายในโครงสร้าง ตัวอย่างเช่น Sparc, PowerPC และ 680x0 CPUs เป็น big-endian ทั้งหมดและค่าเริ่มต้นทั่วไปสำหรับคอมไพเลอร์ Sparc และ PowerPC คือการจัดเรียงสมาชิกของโครงสร้างบนขอบเขต 4 ไบต์ อย่างไรก็ตามคอมไพเลอร์หนึ่งตัวที่ฉันใช้สำหรับ 680x0 จะจัดชิดขอบ 2 ไบต์เท่านั้น - และไม่มีตัวเลือกในการเปลี่ยนการจัดแนว!

ดังนั้นสำหรับโครงสร้างบางอย่างขนาดของ Sparc และ PowerPC จะเท่ากัน แต่มีขนาดเล็กกว่า 680x0 และสมาชิกบางส่วนอยู่ในการชดเชยหน่วยความจำที่แตกต่างกันภายในโครงสร้าง

นี่เป็นปัญหากับโปรเจ็กต์หนึ่งที่ฉันทำงานอยู่เนื่องจากกระบวนการเซิร์ฟเวอร์ที่ทำงานบน Sparc จะสอบถามไคลเอ็นต์และพบว่ามันเป็นบิ๊กเอนด์และคิดว่ามันสามารถพ่นโครงสร้างไบนารีออกมาบนเครือข่ายและไคลเอนต์สามารถรับมือได้ และทำงานได้ดีกับไคลเอนต์ PowerPC และล้มเหลวครั้งใหญ่บนไคลเอนต์ 680x0 ฉันไม่ได้เขียนโค้ดและใช้เวลาพอสมควรในการค้นหาปัญหา แต่มันง่ายที่จะแก้ไขเมื่อฉันทำ

ขอบคุณ @BenVoigt สำหรับความคิดเห็นที่มีประโยชน์มากของคุณเริ่มต้น

ไม่ได้สร้างขึ้นเพื่อบันทึกความทรงจำ

แหล่งที่มาของลินุกซ์ไม่ใช้ช่องบิตเพื่อให้ตรงไปโครงสร้างภายนอก: /usr/include/linux/ip.hมีรหัสนี้สำหรับไบต์แรกของดาต้า IP

struct iphdr {
#if defined(__LITTLE_ENDIAN_BITFIELD)
        __u8    ihl:4,
                version:4;
#elif defined (__BIG_ENDIAN_BITFIELD)
        __u8    version:4,
                ihl:4;
#else
#error  "Please fix <asm/byteorder.h>"
#endif

อย่างไรก็ตามในแง่ของความคิดเห็นของคุณฉันให้พยายามที่จะได้รับการทำงานสำหรับหลายไบต์ฟิลด์บิตfrag_off

แน่นอนคำตอบที่ดีที่สุดคือการใช้คลาสที่อ่าน / เขียนฟิลด์บิตเป็นสตรีม ไม่รับประกันการใช้โครงสร้างฟิลด์ C bit ไม่ต้องพูดถึงถือว่าไม่เป็นมืออาชีพ / ขี้เกียจ / โง่ที่จะใช้สิ่งนี้ในการเขียนโค้ดในโลกแห่งความเป็นจริง