ภาษาโปรแกรมที่ปลอดภัยคืออะไร

ภาษาโปรแกรมที่ปลอดภัย (PL) กำลังได้รับความนิยม ฉันสงสัยว่าคำจำกัดความที่เป็นทางการของ PL ที่ปลอดภัยคืออะไร ตัวอย่างเช่น C ไม่ปลอดภัย แต่ Java นั้นปลอดภัย ฉันสงสัยว่าคุณสมบัติ "ปลอดภัย" ควรนำไปใช้กับการติดตั้ง PL แทนที่จะเป็น PL ถ้าเป็นเช่นนั้นเรามาพูดถึงคำจำกัดความของการใช้ PL อย่างปลอดภัย ความพยายามของฉันในการทำให้แนวคิดนี้เป็นระเบียบกลายเป็นผลลัพธ์ที่แปลกประหลาดดังนั้นฉันจึงอยากได้ยินความคิดเห็นอื่น โปรดอย่าพูดว่า PL ทุกคนมีคำสั่งที่ไม่ปลอดภัย เราสามารถใช้ชุดย่อยที่ปลอดภัยได้เสมอ

เมื่อเราเรียกภาษาที่“ ปลอดภัย” ในบางแง่หมายความว่าอย่างเป็นทางการหมายความว่ามีหลักฐานว่าไม่มีโปรแกรมที่มีรูปแบบที่ดีในภาษาสามารถทำสิ่งที่เราคิดว่าเป็นอันตราย คำว่า "ปลอดภัย" นั้นใช้น้อยกว่าแบบเป็นทางการ แต่นั่นคือสิ่งที่ผู้คนที่นี่เข้าใจถึงคำถามของคุณ มีคำจำกัดความต่าง ๆ มากมายของคุณสมบัติที่เราต้องการให้ภาษา“ ปลอดภัย” มี

สิ่งสำคัญบางประการคือ:

• Andrew Wright และ Matthias Felleisen ได้นิยามคำว่า "ความสมบูรณ์แบบ"ซึ่งมีการกล่าวถึงในหลาย ๆ ที่ (รวมถึง Wikipedia) ในฐานะที่เป็นคำนิยามที่ยอมรับได้ของ "ความปลอดภัยของประเภท" และหลักฐานปี 1994 ของพวกเขาว่า

• ไมเคิลฮิกส์หลายรายการคำนิยามของ“ความปลอดภัยความทรงจำ” ที่นี่ บางรายการเป็นประเภทของข้อผิดพลาดที่ไม่สามารถเกิดขึ้นได้และบางรายการขึ้นอยู่กับการรักษาพอยน์เตอร์เป็นความสามารถ Java รับประกันว่าไม่มีข้อผิดพลาดใด ๆ ที่เป็นไปได้ (เว้นแต่คุณจะใช้คุณลักษณะที่ทำเครื่องหมายไว้อย่างชัดเจนunsafe) โดยให้ตัวรวบรวมขยะจัดการการจัดสรรและการจัดสรรคืนทั้งหมด สนิมทำให้การรับประกันเดียวกัน (อีกครั้งยกเว้นว่าคุณทำเครื่องหมายรหัสไว้อย่างชัดเจนunsafe) ผ่านระบบประเภทเลียนแบบซึ่งต้องการตัวแปรที่จะเป็นเจ้าของหรือยืมก่อนที่จะถูกใช้อย่างมากที่สุดครั้งเดียว

• ในทำนองเดียวกันรหัสปลอดภัยของเธรดมักจะถูกกำหนดเป็นรหัสที่ไม่สามารถแสดงข้อบกพร่องบางประเภทที่เกี่ยวข้องกับเธรดและหน่วยความจำที่ใช้ร่วมกันรวมถึงการแย่งชิงข้อมูลและการหยุดชะงัก คุณสมบัติเหล่านี้มักจะมีการบังคับใช้ในระดับภาษา: สนิมรับประกันได้ว่าข้อมูลการแข่งขันไม่สามารถเกิดขึ้นได้ในระบบประเภทของมัน C ++ รับประกันได้ว่าstd::shared_ptrสมาร์ทพอยน์เตอร์ไปยังวัตถุเดียวกันในหลายเธรดจะไม่ลบวัตถุก่อนกำหนดหรือล้มเหลว จะถูกทำลาย, C และ C ++ นอกจากนี้ยังมีatomicตัวแปรที่สร้างขึ้นในภาษาที่มีการดำเนินการปรมาณูรับประกันว่าจะบังคับใช้ความสอดคล้องหน่วยความจำบางชนิดถ้าใช้อย่างถูกต้อง MPI จำกัด การสื่อสารระหว่างกระบวนการกับข้อความที่ชัดเจนและ OpenMP มีไวยากรณ์เพื่อให้แน่ใจว่าการเข้าถึงตัวแปรจากเธรดที่แตกต่างนั้นปลอดภัย

• คุณสมบัติที่หน่วยความจำจะไม่รั่วไหลมักจะเรียกว่าปลอดภัยสำหรับพื้นที่ การรวบรวมขยะอัตโนมัติเป็นคุณสมบัติภาษาเดียวที่จะทำให้มั่นใจได้

• หลายภาษามีการรับประกันว่าการทำงานของมันจะมีผลลัพธ์ที่ชัดเจนและโปรแกรมของมันจะมีความประพฤติดี ในฐานะที่เป็นตัวอย่างของซูเปอร์แคทข้างต้น C ทำสิ่งนี้สำหรับเลขคณิตที่ไม่ได้ลงนาม (รับประกันการห่อรอบอย่างปลอดภัย) แต่ไม่ได้ลงนามทางคณิตศาสตร์ (ที่ล้นได้รับอนุญาตให้ก่อให้เกิดข้อผิดพลาดโดยพลการเพราะ C จำเป็นต้องสนับสนุน CPU มากเกิน) แต่บางครั้งภาษาก็จะแปลงปริมาณที่ไม่ได้รับการรับรองให้กลายเป็นสิ่งที่ถูกลงชื่อ

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

• บางภาษาเช่น SPARK หรือ OCaml ได้รับการออกแบบมาเพื่ออำนวยความสะดวกในการพิสูจน์ความถูกต้องของโปรแกรม สิ่งนี้อาจหรืออาจจะไม่ได้อธิบายว่าเป็น "ปลอดภัย" จากข้อบกพร่อง

• พิสูจน์ว่าระบบไม่สามารถละเมิดรูปแบบการรักษาความปลอดภัยที่เป็นทางการได้ (เช่นคำว่า "ระบบใด ๆ ที่พิสูจน์ได้ว่ามีความปลอดภัยอาจไม่ใช่")

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

หากคุณได้รับสำเนาของประเภทและภาษาการเขียนโปรแกรมของเบนจามินเพียร์ซในบทนำเขามีภาพรวมที่ดีเกี่ยวกับแง่มุมต่าง ๆ ของคำว่า "ภาษาปลอดภัย"

การตีความที่นำเสนอหนึ่งคำที่คุณอาจพบว่าน่าสนใจคือ:

“ ภาษาที่ปลอดภัยถูกกำหนดไว้อย่างสมบูรณ์ในคู่มือของโปรแกรมเมอร์” ให้คำจำกัดความของภาษาเป็นชุดของสิ่งที่โปรแกรมเมอร์ต้องเข้าใจเพื่อทำนายพฤติกรรมของทุกโปรแกรมในภาษา จากนั้นคู่มือสำหรับภาษาอย่าง C ไม่ได้เป็นคำนิยามเนื่องจากพฤติกรรมของบางโปรแกรม (เช่นคนที่เกี่ยวข้องกับการเข้าถึงอาเรย์ที่ไม่ได้ตรวจสอบหรือตัวชี้ทางคณิตศาสตร์) ไม่สามารถทำนายได้โดยไม่ทราบรายละเอียดว่าคอมไพเลอร์ C ฯลฯ และโปรแกรมเดียวกันอาจมีพฤติกรรมที่แตกต่างกันมากเมื่อดำเนินการโดยคอมไพเลอร์ต่างกัน

ดังนั้นฉันจะลังเลที่จะใช้คำว่า "ไม่ปลอดภัย" เพื่ออ้างถึงการใช้ภาษาโปรแกรม หากคำที่ไม่ได้กำหนดในภาษาสร้างพฤติกรรมที่แตกต่างกันในการใช้งานที่แตกต่างกันการใช้งานอย่างใดอย่างหนึ่งอาจเป็นการทำงานของผลิตภัณฑ์ที่อาจคาดหวังได้มากกว่า แต่ฉันจะไม่เรียกมันว่า "ปลอดภัย"

ปลอดภัยไม่ไบนารีมันเป็นความต่อเนื่อง

การพูดอย่างไม่เป็นทางการความปลอดภัยหมายถึงการต่อต้านข้อบกพร่อง 2 สิ่งที่ถูกกล่าวถึงบ่อยที่สุดคือ:

• ความปลอดภัยของหน่วยความจำ: ภาษาและการใช้งานนั้นป้องกันข้อผิดพลาดเกี่ยวกับหน่วยความจำที่หลากหลายเช่นการใช้งานหลังจากใช้งานฟรีไม่มีการ จำกัด การเข้าถึงสองเท่า
• ความปลอดภัยของประเภท: ภาษาและการใช้งานนั้นป้องกันข้อผิดพลาดที่เกี่ยวข้องกับประเภทต่างๆเช่นการปลดเปลื้องที่ไม่ถูกเลือก ...

สิ่งเหล่านี้ไม่ใช่คลาสของบั๊กแต่เพียงผู้เดียวที่ป้องกันภาษาเสรีภาพในการแข่งขันข้อมูลหรือการหยุดชะงักอิสระเป็นสิ่งที่น่าพึงพอใจการพิสูจน์ความถูกต้องจะค่อนข้างหวาน ฯลฯ

เพียงแค่โปรแกรมที่ไม่ถูกต้องมักจะถูกพิจารณาว่าเป็น "ไม่ปลอดภัย" (เป็นบั๊กกี้เท่านั้น) และโดยทั่วไปคำว่าความปลอดภัยนั้นสงวนไว้สำหรับการรับประกันที่ส่งผลต่อความสามารถของเราในการให้เหตุผลเกี่ยวกับโปรแกรม ดังนั้น C, C ++ หรือ Go ที่มีพฤติกรรมที่ไม่ได้กำหนดไม่ปลอดภัย

และแน่นอนว่ายังมีภาษาที่มีชุดย่อยที่ไม่ปลอดภัย (Java, Rust, ... ) ซึ่งแยกส่วนที่ผู้พัฒนามีหน้าที่รับผิดชอบในการรักษาการรับประกันภาษาและคอมไพเลอร์อยู่ในโหมด "hands-off" ภาษายังคงขนานนามโดยทั่วไปว่าปลอดภัยแม้จะมีช่องโหว่นี้เป็นคำจำกัดความที่ใช้งานได้จริง

แม้ว่าฉันจะไม่เห็นด้วยกับคำตอบของ DW แต่ฉันคิดว่ามันเป็นส่วนหนึ่งของ "ปลอดภัย" ที่ไม่ได้รับการแก้ไข

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

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

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

ความแตกต่างพื้นฐานระหว่าง C และ Java คือถ้าใครหลีกเลี่ยงคุณลักษณะบางอย่างที่สามารถระบุตัวได้ง่ายของ Java (เช่นที่อยู่ในUnsafenamespace) ทุกการกระทำที่เป็นไปได้หนึ่งอาจพยายาม - รวมทั้ง "ผิดพลาด" - จะมีช่วงที่ จำกัด . แม้ว่าสิ่งนี้จะ จำกัด สิ่งที่สามารถทำได้ใน Java อย่างน้อยโดยไม่ต้องใช้Unsafenamespace แต่ก็สามารถจำกัดความเสียหายที่อาจเกิดขึ้นจากโปรแกรมที่ผิดพลาดหรือที่สำคัญกว่านั้นคือโปรแกรมที่ประมวลผลอย่างถูกต้อง ไฟล์ที่ถูกต้อง แต่ไม่ได้รับการป้องกันโดยเฉพาะกับไฟล์ที่ผิดพลาด

ตามเนื้อผ้าคอมไพเลอร์ C จะประมวลผลการกระทำมากมายในรูปแบบมาตรฐานที่กำหนดในกรณี "ปกติ" ในขณะที่การประมวลผลหลายมุมกรณี "ในลักษณะลักษณะของสภาพแวดล้อม" หากมีใครใช้ซีพียูที่จะลัดวงจรและลุกไหม้หากมีตัวเลขล้นเกิดขึ้นและต้องการหลีกเลี่ยง CPU ที่ติดไฟจะต้องเขียนโค้ดเพื่อหลีกเลี่ยงการล้นของตัวเลข อย่างไรก็ตามหากมีใครใช้ซีพียูซึ่งจะตัดค่าอย่างสมบูรณ์แบบอย่างมีความสุขอย่างสมบูรณ์แบบในแบบของสองคนก็ไม่จำเป็นต้องหลีกเลี่ยงการล้นในกรณีที่การตัดเช่นนั้นจะส่งผลให้พฤติกรรมที่ยอมรับได้

Modern C ก้าวไปอีกขั้น: แม้ว่าเป้าหมายกำลังกำหนดแพลตฟอร์มซึ่งจะกำหนดพฤติกรรมสำหรับบางอย่างเช่นตัวเลขล้นซึ่งมาตรฐานจะไม่มีข้อกำหนด แต่การล้นในส่วนหนึ่งของโปรแกรมอาจส่งผลกระทบต่อพฤติกรรมของส่วนอื่น ๆ ของ โปรแกรมในลักษณะโดยพลการไม่ผูกพันตามกฎหมายของเวลาและเวรกรรม ตัวอย่างเช่นลองพิจารณาสิ่งต่อไปนี้:

 uint32_t test(uint16_t x)
 {
   if (x < 50000) foo(x);
   return x*x; // Note x will promote to "int" if that type is >16 bits.
 }

คอมไพเลอร์ "modern" C ที่ให้บางอย่างเช่นด้านบนอาจสรุปได้ว่าเนื่องจากการคำนวณของ x * x จะล้นถ้า x มากกว่า 46340 มันสามารถทำการเรียกไปที่ "foo" โดยไม่มีเงื่อนไข โปรดทราบว่าแม้ว่ามันจะเป็นที่ยอมรับได้ที่จะมีโปรแกรมยุติอย่างผิดปกติถ้า x อยู่นอกช่วงหรือฟังก์ชั่นคืนค่าใด ๆ ในกรณีเช่นนี้การเรียก foo () ด้วยการอยู่นอกขอบเขต x อาจทำให้เกิดความเสียหายเกินกว่า ความเป็นไปได้เหล่านั้นอย่างใดอย่างหนึ่ง ดั้งเดิม C จะไม่ให้อุปกรณ์ความปลอดภัยใด ๆ นอกเหนือจากที่โปรแกรมเมอร์และแพลตฟอร์มที่ให้มา แต่จะอนุญาตให้อุปกรณ์ความปลอดภัยเพื่อจำกัดความเสียหายจากสถานการณ์ที่ไม่คาดคิด Modern C จะหลีกเลี่ยงอุปกรณ์ความปลอดภัยที่ไม่มีประสิทธิภาพ 100% ในการควบคุมทุกสิ่ง

ความถูกต้องมีหลายชั้นในภาษา เพื่อเพิ่มความเป็นนามธรรม:

• โปรแกรมไม่กี่ข้อผิดพลาด (เฉพาะที่สามารถพิสูจน์ความถูกต้อง) คนอื่น ๆ กล่าวถึงแล้วว่าการควบคุมข้อผิดพลาดนั้นเป็นประเด็นด้านความปลอดภัยที่เป็นรูปธรรมที่สุด ภาษาที่ทำงานในเครื่องเสมือนเช่น Java และ. net มักจะปลอดภัยกว่าในแง่นี้: ข้อผิดพลาดของโปรแกรมจะถูกดักจับและจัดการตามวิธีที่กำหนด ¹

• ในระดับต่อไปข้อผิดพลาดที่ตรวจพบในเวลารวบรวมแทนที่จะเป็นเวลาทำงานทำให้ภาษาปลอดภัยยิ่งขึ้น โปรแกรมที่ถูกต้องทางวากยสัมพันธ์ควรมีความหมายถูกต้องมากที่สุด แน่นอนว่าคอมไพเลอร์ไม่สามารถรู้ภาพรวมได้ดังนั้นสิ่งนี้จึงเกี่ยวข้องกับระดับรายละเอียด ประเภทข้อมูลที่แข็งแกร่งและชัดเจนเป็นหนึ่งในด้านความปลอดภัยในระดับนี้ อาจกล่าวได้ว่าภาษาควรทำให้เกิดข้อผิดพลาดบางประเภทได้ยาก(ข้อผิดพลาดประเภทการเข้าถึงนอกขอบเขตตัวแปรที่ไม่กำหนดค่าเริ่มต้น ฯลฯ ) ข้อมูลชนิดรันไทม์เช่นอาร์เรย์ที่มีข้อมูลความยาวหลีกเลี่ยงข้อผิดพลาด ฉันตั้งโปรแกรม Ada 83 ในวิทยาลัยและพบว่าโดยทั่วไปแล้วโปรแกรม Ada ที่รวบรวมอาจมีลำดับความผิดพลาดน้อยกว่าโปรแกรม C ที่เกี่ยวข้อง เพียงแค่ใช้ความสามารถของ Ada ในการกำหนดประเภทจำนวนเต็มซึ่งไม่สามารถกำหนดได้โดยไม่ต้องมีการแปลงอย่างชัดเจน: ยานอวกาศทั้งหมดขัดข้องเพราะเท้าและเมตรสับสนซึ่งหนึ่งสามารถหลีกเลี่ยงกับ Ada ได้เล็กน้อย

• ในระดับต่อไปภาษาควรจัดให้มีวิธีการหลีกเลี่ยงรหัสสำเร็จรูป หากคุณต้องเขียนคอนเทนเนอร์ของคุณเองหรือเรียงลำดับของพวกเขาหรือเรียงต่อกันของพวกเขาหรือถ้าคุณต้องเขียนของคุณเองstring::trim()คุณจะทำผิดพลาด เนื่องจากระดับนามธรรมเพิ่มขึ้นเกณฑ์นี้เกี่ยวข้องกับภาษาที่เหมาะสมเช่นเดียวกับห้องสมุดมาตรฐานของภาษา

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

• ภาษาควรให้ความหมายสำหรับการทำให้เป็นโมดูลและการทำงานร่วมกัน ประเภทที่แข็งแกร่งและซับซ้อนที่ผู้ใช้กำหนดเองจากด้านบนช่วยสร้าง API ที่แสดงออก

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

โปรดอย่าพูดว่า PL ทุกคนมีคำสั่งที่ไม่ปลอดภัย เราสามารถใช้เซ็ตย่อยที่ปลอดภัยได้เสมอ

ทุกภาษาที่ฉันรู้จักมีวิธีการเขียนโปรแกรมที่ผิดกฎหมายที่สามารถ (รวบรวมและ) และทุกภาษาที่ฉันรู้มีเซตย่อยที่ปลอดภัย ดังนั้นคำถามของคุณคืออะไรจริงๆ?

ความปลอดภัยมีหลายมิติและเป็นส่วนตัว

บางภาษามีการทำงานจำนวนมากที่ "ไม่ปลอดภัย" อื่น ๆ มีการดำเนินการดังกล่าวน้อยลง ในบางภาษาวิธีการเริ่มต้นในการทำบางสิ่งนั้นไม่ปลอดภัยโดยเนื้อแท้ วิธีอื่นที่เป็นค่าเริ่มต้นนั้นปลอดภัย ในบางภาษามีชุดย่อย "ไม่ปลอดภัย" ที่ชัดเจน ในภาษาอื่น ๆ ไม่มีชุดย่อยดังกล่าวเลย

ในบางภาษา "ความปลอดภัย" หมายถึงความปลอดภัยของหน่วยความจำโดยเฉพาะ - บริการที่นำเสนอโดยห้องสมุดมาตรฐานและ / หรือรันไทม์ที่การละเมิดการเข้าถึงหน่วยความจำทำได้ยากหรือเป็นไปไม่ได้ ในภาษาอื่น ๆ "ความปลอดภัย" รวมถึงความปลอดภัยของเธรดอย่างชัดเจน ในภาษาอื่น "ความปลอดภัย" หมายถึงการรับประกันว่าโปรแกรมจะไม่ผิดพลาด (ข้อกำหนดที่รวมถึงการไม่อนุญาตให้มีข้อยกเว้นที่ไม่ได้ตรวจสอบใด ๆ ) สุดท้ายในหลาย ๆ ภาษา "ความปลอดภัย" หมายถึงความปลอดภัยของประเภท - หากระบบประเภทมีความสอดคล้องในบางวิธีมันก็บอกว่าเป็น "เสียง" (บังเอิญ Java และ C # ไม่มีระบบเสียงที่สมบูรณ์แบบ)

และในบางภาษาความหมายที่แตกต่างกันทั้งหมดของ "ความปลอดภัย" ถือว่าเป็นส่วนย่อยของความปลอดภัยประเภท (เช่น Rust และ Pony บรรลุความปลอดภัยด้ายผ่านคุณสมบัติของระบบประเภท)

คำตอบนี้กว้างขึ้นอีกเล็กน้อย คำว่าปลอดภัยและความปลอดภัยในช่วงไม่กี่สิบปีที่ผ่านมาได้ถูกทำลายโดยบางส่วนที่มุ่งเน้นทางการเมืองของสังคมที่พูดภาษาอังกฤษเช่นการใช้งานทั่วไปของพวกเขาเกือบจะไม่มีคำนิยาม อย่างไรก็ตามสำหรับวิชาทางเทคนิคฉันยังคงกลับไปเพื่อกำหนด "ความปลอดภัย" และ "ปลอดภัย" เป็น: อุปกรณ์ที่ป้องกันการใช้งานโดยไม่ตั้งใจหรือสิ่งที่ทำให้การใช้งานโดยไม่ตั้งใจทำได้ยากขึ้นและสถานะของการอยู่ภายใต้การคุ้มครองของอุปกรณ์ดังกล่าว .
ดังนั้นภาษาที่ปลอดภัยจึงมีอุปกรณ์ที่จะ จำกัด คลาสของข้อบกพร่องบางประเภท แน่นอนว่าข้อ จำกัด นั้นมาพร้อมกับความไม่สะดวกหรือในบางกรณีและนั่นก็ไม่ได้หมายความว่าภาษาที่ "ไม่ปลอดภัย" จะส่งผลให้เกิดข้อบกพร่อง เช่นฉันไม่มีจุกความปลอดภัยในส้อมของฉันและมีการจัดการมานานหลายทศวรรษโดยไม่มีความพยายามมากเพื่อหลีกเลี่ยงการแทงตาขณะกิน แน่นอนว่ามีความพยายามน้อยกว่าการใช้จุกไม้ก๊อก ดังนั้นความปลอดภัยจึงมาพร้อมกับราคาที่ต้องพิจารณา (cork fork เป็นการอ้างอิงถึงตัวละครของ Steve Martin)