ในระบบสิทธิ์ไฟล์ของ Unix คำสั่งอย่าง chmod 640 คือตรรกะ bitwise ล้วน ๆ — แต่ละหลักรวมสามบิตสิทธิ์ (อ่าน เขียน รัน) เข้าด้วยกันด้วย OR และการตรวจสอบว่าสิทธิ์ใดสิทธิ์หนึ่งถูกเปิดอยู่หรือไม่ก็ทำได้ด้วย AND กับ mask ที่เหมาะสมเพียงครั้งเดียว
AND, OR, XOR, NOT — สี่การดำเนินการพื้นฐาน
- AND (&) — บิตผลลัพธ์เป็น 1 ก็ต่อเมื่อบิตนำเข้าทั้งสองเป็น 1 ใช้ตรวจสอบว่า flag ใดถูกตั้งอยู่ใน mask หรือไม่
- OR (|) — บิตผลลัพธ์เป็น 1 หากบิตนำเข้าอย่างน้อยหนึ่งตัวเป็น 1 ใช้รวม flag หลายตัวเข้าเป็นค่าเดียว
- XOR (^) — บิตผลลัพธ์เป็น 1 หากบิตนำเข้าต่างกัน การใช้ XOR สองครั้งกับค่าเดียวกันจะคืนค่าดั้งเดิม
- NOT (~) — กลับค่าทุกบิตของตัวเลข
bitwise AND ต่างจาก logical AND อย่างไร
logical AND (&& ในภาษาส่วนใหญ่) ทำงานกับค่า boolean ทั้งก้อนและให้ผลลัพธ์เป็น true/false ในขณะที่ bitwise AND (&) ประมวลผลแต่ละบิตของตัวเลขสองตัวแยกกันและคืนค่าเป็นตัวเลข การสับสนระหว่างสองอย่างนี้เป็นสาเหตุทั่วไปของบั๊ก โดยเฉพาะเพราะในบางภาษาทั้งสองแบบคอมไพล์ผ่านได้โดยไม่มี error เรื่อง type เลย
ทำไมเครื่องมือนี้จึงมักใช้คู่กับตัวแปลงฐานเลข
ค่า mask สิทธิ์เป็นเลขฐานสิบ 6 ไม่บอกอะไรเลยเมื่อมองผ่าน ๆ แต่ค่าเดียวกันเขียนเป็น 0b110 จะแสดงทันทีว่า "อ่านและเขียน แต่รันไม่ได้" นี่คือเหตุผลที่ bitwise operation แทบทุกครั้งจะคิดในฐานสองหรือฐานสิบหก ไม่ใช่ฐานสิบ — ตัวแปลงฐานเลขจึงมักเป็นขั้นตอนแรกก่อนที่ AND/OR/XOR จะมีความหมายให้มองเห็นได้จริง
ทำไมต้องใช้สิ่งนี้
- จัดเก็บและตรวจสอบชุดแฟล็ก boolean อย่างมีประสิทธิภาพในตัวเลขเดียว
- เข้าใจโค้ดระดับต่ำที่ทำงานกับโปรโตคอลเครือข่ายหรือรูปแบบไบนารี
- ปรับปรุงการคำนวณที่ bitwise operation เร็วกว่าเลขคณิตปกติ
กับดักลำดับความสำคัญของตัวดำเนินการ
ในภาษาโปรแกรมส่วนใหญ่ bitwise operator & และ | มีลำดับความสำคัญต่ำกว่า operator เปรียบเทียบ — ดังนั้นนิพจน์อย่าง if (a & b == c) จริง ๆ แล้วจะถูกประเมินเป็น a & (b == c) ไม่ใช่อย่างที่ผู้เขียนตั้งใจไว้ตามปกติ นี่เป็นสาเหตุที่พบบ่อยที่สุดอย่างหนึ่งของบั๊กที่ตรวจพบได้ยากเมื่อทำงานกับ bitmask และวิธีที่เชื่อถือได้ในการหลีกเลี่ยงคือใส่วงเล็บอย่างชัดเจนรอบ bitwise operation เสมอ