ทำไมการใช้ alloca () จึงไม่ถือว่าเป็นแนวปฏิบัติที่ดี?

alloca()malloc()หน่วยความจำที่จัดสรรในกองมากกว่าในกองเช่นในกรณีของ ดังนั้นเมื่อฉันกลับจากรูทีนหน่วยความจำจะถูกปล่อยให้เป็นอิสระ ดังนั้นที่จริงแล้วสิ่งนี้แก้ปัญหาของฉันในการเพิ่มหน่วยความจำที่จัดสรรแบบไดนามิก การเพิ่มจำนวนของหน่วยความจำที่จัดสรรผ่านmalloc()นั้นเป็นเรื่องที่น่าปวดหัวอย่างมากและหากพลาดไปก็จะทำให้เกิดปัญหาหน่วยความจำทุกประเภท

ทำไมการใช้งานalloca()ท้อแท้ทั้งๆที่มีคุณสมบัติข้างต้น?

คำตอบอยู่ที่นั่นในmanหน้า (อย่างน้อยบนLinux ):

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

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

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

ในไฟล์ส่วนหัว:

void DoSomething() {
   wchar_t* pStr = alloca(100);
   //......
}

ในไฟล์การนำไปใช้งาน:

void Process() {
   for (i = 0; i < 1000000; i++) {
     DoSomething();
   }
}

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

ดังนั้นบทเรียนคือ - อย่าใช้allocaในฟังก์ชั่นที่คุณคิดว่าอาจจะมีการอนุมาน

คำถามเก่า แต่ไม่มีใครพูดถึงว่ามันควรจะถูกแทนที่ด้วยอาร์เรย์ความยาวตัวแปร

char arr[size];

แทน

char *arr=alloca(size);

มันอยู่ในมาตรฐาน C99 และมีอยู่เป็นส่วนขยายคอมไพเลอร์ในคอมไพเลอร์จำนวนมาก

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

คุณสามารถค่อนข้างปลอดภัยถ้าคุณ

• ห้ามส่งคืนพอยน์เตอร์หรือสิ่งใด ๆ ที่มีอยู่
• อย่าเก็บตัวชี้ไว้ในโครงสร้างใด ๆ ที่จัดสรรไว้บนกอง
• อย่าปล่อยให้เธรดอื่นใช้ตัวชี้

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

ดังที่ได้กล่าวไว้ในการโพสต์ของกลุ่มข่าวนี้มีสาเหตุบางประการที่การใช้งานallocaนั้นถือเป็นเรื่องยากและอันตราย

• allocaไม่ได้คอมไพเลอร์สนับสนุน
• คอมไพเลอร์บางตัวตีความพฤติกรรมที่ตั้งใจไว้allocaแตกต่างกันดังนั้นจึงไม่รับประกันความสะดวกในการพกพาแม้ระหว่างคอมไพเลอร์ที่สนับสนุน
• การใช้งานบางอย่างเป็นรถ

ปัญหาหนึ่งคือมันไม่ได้มาตรฐานแม้ว่าจะได้รับการสนับสนุนอย่างกว้างขวาง สิ่งอื่น ๆ ที่เท่าเทียมกันฉันมักจะใช้ฟังก์ชั่นมาตรฐานมากกว่าส่วนขยายคอมไพเลอร์ทั่วไป

ยังคงใช้ alloca ท้อทำไม?

ฉันไม่เข้าใจฉันทามติดังกล่าว ข้อดีที่แข็งแกร่งมากมาย ข้อเสียไม่กี่:

• C99 มีอาร์เรย์ความยาวผันแปรซึ่งมักจะถูกใช้เป็นพิเศษเนื่องจากสัญกรณ์มีความสอดคล้องกับอาร์เรย์ที่มีความยาวคงที่และโดยรวมที่ใช้งานง่าย
• ระบบจำนวนมากมีหน่วยความจำรวม / ที่อยู่พื้นที่ว่างน้อยกว่าสำหรับสแต็กมากกว่าที่ทำสำหรับฮีปซึ่งทำให้โปรแกรมมีความอ่อนไหวต่อความจำของหน่วยความจำมากขึ้นเล็กน้อย (ผ่านสแต็คล้น): นี่อาจเป็นสิ่งที่ดี สาเหตุที่สแต็คไม่เติบโตโดยอัตโนมัติตามที่ฮีปทำคือป้องกันโปรแกรมที่ไม่อยู่ในการควบคุมไม่ให้เกิดผลกระทบต่อทั้งเครื่อง
• เมื่อใช้ในขอบเขตภายในเพิ่มเติม (เช่น a whileหรือforloop) หรือในหลายขอบเขตหน่วยความจำจะสะสมตามการวนซ้ำ / ขอบเขตและจะไม่ปล่อยจนกว่าฟังก์ชันจะออก: ฟังก์ชันนี้ขัดแย้งกับตัวแปรปกติที่กำหนดไว้ในขอบเขตของโครงสร้างการควบคุม (เช่นfor {int i = 0; i < 2; ++i) { X }จะสะสมallocaหน่วยความจำที่ร้องขอที่ X แต่หน่วยความจำสำหรับอาร์เรย์ที่มีขนาดคงที่จะถูกรีไซเคิลต่อการทำซ้ำ)
• คอมไพเลอร์ที่ทันสมัยมักจะไม่inlineทำงานที่เรียกว่าallocaแต่ถ้าคุณบังคับพวกเขาแล้วallocaจะเกิดขึ้นในบริบทของผู้โทร (เช่นสแต็กจะไม่ออกจนกว่าผู้โทรกลับ)
• เมื่อนานมาแล้วได้allocaเปลี่ยนจากฟีเจอร์ / แฮ็คที่ไม่ใช่แบบพกพาเป็นส่วนขยายมาตรฐาน แต่การรับรู้เชิงลบบางอย่างอาจยังคงมีอยู่
• อายุการใช้งานถูกผูกไว้กับขอบเขตของฟังก์ชั่นซึ่งอาจเหมาะสมกับโปรแกรมเมอร์มากกว่าmallocการควบคุมอย่างชัดเจน
• ต้องใช้การmallocกระตุ้นให้คิดถึงการจัดสรรคืน - หากมีการจัดการผ่านฟังก์ชั่น wrapper (เช่นWonderfulObject_DestructorFree(ptr)) จากนั้นฟังก์ชั่นจะเป็นจุดสำหรับการดำเนินการล้างข้อมูลการดำเนินงาน (เช่นตัวอธิบายไฟล์ปิดการปลดปล่อยพอยน์เตอร์ภายในหรือทำการบันทึกบางอย่าง) รหัส: บางครั้งมันเป็นรูปแบบที่ดีที่จะนำมาใช้อย่างสม่ำเสมอ
  • ในรูปแบบการเขียนโปรแกรมแบบหลอก OO นี้เป็นเรื่องปกติที่จะต้องการWonderfulObject* p = WonderfulObject_AllocConstructor();- ที่เป็นไปได้เมื่อ "constructor" เป็นฟังก์ชั่นmallocหน่วยความจำที่ส่งคืนหน่วยความจำ (เนื่องจากหน่วยความจำยังคงถูกจัดสรรหลังจากฟังก์ชันส่งคืนค่าที่เก็บไว้p) ถ้า "constructor" ใช้alloca
    • มาโครรุ่นหนึ่งWonderfulObject_AllocConstructorสามารถบรรลุสิ่งนี้ได้ แต่ "มาโครนั้นชั่วร้าย" ซึ่งพวกเขาสามารถขัดแย้งกันและไม่ใช่โค้ดแมโครและสร้างการแทนที่ที่ไม่ได้ตั้งใจและปัญหาที่ยากต่อการวินิจฉัยที่ตามมา
  • freeการดำเนินการที่หายไปสามารถตรวจพบได้โดย ValGrind, Purify ฯลฯ แต่การเรียก "destructor" ที่หายไปนั้นไม่สามารถตรวจพบได้ตลอดเวลา - ผลประโยชน์ที่สำคัญเพียงอย่างเดียวในแง่ของการบังคับใช้การใช้งานที่ตั้งใจไว้ alloca()การใช้งานบางอย่าง(เช่น GCC) ใช้มาโครแบบอินไลน์สำหรับalloca()ดังนั้นการทดแทนรันไทม์ของไลบรารีการวินิจฉัยการใช้หน่วยความจำจึงไม่สามารถทำได้สำหรับmalloc/ realloc/ free(เช่นรั้วไฟฟ้า)
• การใช้งานบางอย่างมีปัญหาเล็กน้อย: ตัวอย่างเช่นจาก manpage Linux:

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

ฉันรู้ว่าคำถามนี้ถูกติดแท็ก C แต่ในฐานะโปรแกรมเมอร์ C ++ ฉันคิดว่าฉันใช้ C ++ เพื่อแสดงอรรถประโยชน์ที่เป็นไปได้ของalloca: โค้ดด้านล่าง (และที่นี่ที่ ideone ) สร้างเวกเตอร์การติดตามเวกเตอร์ชนิด polymorphic ขนาดแตกต่างกัน อายุการใช้งานเชื่อมโยงกับฟังก์ชันส่งคืน) แทนที่จะจัดสรรฮีป

#include <alloca.h>
#include <iostream>
#include <vector>

struct Base
{
    virtual ~Base() { }
    virtual int to_int() const = 0;
};

struct Integer : Base
{
    Integer(int n) : n_(n) { }
    int to_int() const { return n_; }
    int n_;
};

struct Double : Base
{
    Double(double n) : n_(n) { }
    int to_int() const { return -n_; }
    double n_;
};

inline Base* factory(double d) __attribute__((always_inline));

inline Base* factory(double d)
{
    if ((double)(int)d != d)
        return new (alloca(sizeof(Double))) Double(d);
    else
        return new (alloca(sizeof(Integer))) Integer(d);
}

int main()
{
    std::vector<Base*> numbers;
    numbers.push_back(factory(29.3));
    numbers.push_back(factory(29));
    numbers.push_back(factory(7.1));
    numbers.push_back(factory(2));
    numbers.push_back(factory(231.0));
    for (std::vector<Base*>::const_iterator i = numbers.begin();
         i != numbers.end(); ++i)
    {
        std::cout << *i << ' ' << (*i)->to_int() << '\n';
        (*i)->~Base();   // optionally / else Undefined Behaviour iff the
                         // program depends on side effects of destructor
    }
}

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

กล่าวอีกนัยหนึ่งalloca( 0x00ffffff )เป็นสิ่งที่อันตรายและมีแนวโน้มที่จะทำให้เกิดน้ำท่วมมากเท่าที่char hugeArray[ 0x00ffffff ];ควร ระมัดระวังและมีเหตุผลและคุณจะสบายดี

คำตอบที่น่าสนใจมากมายสำหรับคำถาม "เก่า" นี้แม้จะมีคำตอบที่ค่อนข้างใหม่ แต่ฉันไม่พบสิ่งใดเลยที่พูดถึงเรื่องนี้ ....

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

ฉันพบว่าข้อความอ้างอิงใน .... ตกลงฉันทำข้อความนั้นขึ้น แต่ลองคิดดูสิ ....

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

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

alloca() (หรือ VLAs) อาจเป็นเพียงเครื่องมือที่เหมาะสมสำหรับงาน

ฉันได้เห็นเวลาและเวลาอีกครั้งที่โปรแกรมเมอร์สร้างบัฟเฟอร์สแต็กจัดสรร "ใหญ่พอที่จะรองรับกรณีที่เป็นไปได้" ในทรีคอลที่ซ้อนกันอย่างลึกการใช้รูปแบบ (anti -?) ซ้ำ ๆ จะนำไปสู่การใช้สแต็กที่พูดเกินจริง (ลองนึกภาพสายเรียกเข้าลึก 20 ระดับซึ่งแต่ละระดับด้วยเหตุผลที่แตกต่างกันฟังก์ชั่นสุ่มจัดสรรจัดสรรบัฟเฟอร์ที่ 1024 ไบต์ "ตาบอดปลอดภัย" โดยทั่วไปแล้วจะใช้เพียง 16 หรือน้อยกว่าเท่านั้น กรณีที่หายากอาจใช้มากขึ้น) ทางเลือกคือการใช้alloca()หรือ VLAs และจัดสรรพื้นที่สแต็คให้มากที่สุดเท่าที่ความต้องการของฟังก์ชันของคุณเพื่อหลีกเลี่ยงการสร้างสแต็กโดยไม่จำเป็น หวังว่าเมื่อหนึ่งฟังก์ชันใน call tree ต้องการการจัดสรรที่มีขนาดใหญ่กว่าปกติส่วนอื่น ๆ ใน call tree ยังคงใช้การจัดสรรขนาดเล็กตามปกติและการใช้งานโดยรวมของแอปพลิเคชันโดยรวมนั้นน้อยกว่าอย่างมาก .

แต่ถ้าคุณเลือกที่จะใช้alloca()...

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

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

คุณสามารถตรวจสอบข้อยกเว้น SEH นี้และโทร _resetstkoflw เพื่อรีเซ็ตสแต็กและดำเนินการต่อด้วยวิธีที่สนุกสนาน มันไม่เหมาะ แต่เป็นอีกกลไกหนึ่งที่อย่างน้อยก็รู้ว่ามีบางอย่างผิดปกติเมื่อสิ่งที่กระทบแฟน ๆ * ระวังอาจมีบางสิ่งที่คล้ายกันซึ่งฉันไม่ทราบ

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

นอกจากนี้ยังไม่อนุญาตให้มีการรั่วไหลของหน่วยความจำ alloca ไม่ก่อให้เกิดการกระจายตัวของหน่วยความจำซึ่งเป็นสิ่งสำคัญสวย ฉันไม่คิดว่า alloca เป็นการฝึกที่ไม่ดีถ้าคุณใช้อย่างชาญฉลาดซึ่งเป็นเรื่องจริงสำหรับทุกสิ่ง :-)

alloca ()ดีและมีประสิทธิภาพ ... แต่มันก็แตกได้เช่นกัน

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

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

หากคุณต้องการ C จริงๆคุณสามารถใช้ VLA (ไม่มี vla ใน C ++, แย่มาก) พวกเขาดีกว่า alloca () เกี่ยวกับพฤติกรรมขอบเขตและความมั่นคง อย่างที่ฉันเห็นมันVLAเป็นแบบalloca () ที่ถูกต้อง

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

นี่คือเหตุผล:

char x;
char *y=malloc(1);
char *z=alloca(&x-y);
*z = 1;

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

แทบทุกรหัสใช้ allocaและ / หรือ C99 vlas ทั้งหมดมีข้อบกพร่องร้ายแรงซึ่งจะนำไปสู่การล่ม (ถ้าคุณโชคดี) หรือการประนีประนอมสิทธิ์ (ถ้าคุณไม่โชคดีมาก)

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

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

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

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

หนึ่งในอันตรายด้วยallocaคือว่าlongjmprewinds มัน

นั่นคือจะบอกว่าถ้าคุณบันทึกบริบทด้วยsetjmpแล้วallocaหน่วยความจำบางส่วนแล้วlongjmpกับบริบทคุณอาจสูญเสียallocaหน่วยความจำ ตัวชี้สแต็กกลับมาอยู่ในตำแหน่งเดิมดังนั้นหน่วยความจำจึงไม่ถูกสงวนไว้อีกต่อไป ถ้าคุณเรียกใช้ฟังก์ชันหรือทำอีกคุณจะบังคับเดิมallocaalloca

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

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

allocaอนึ่งนี้ถ้ามันวิธีการทำงานนั้นให้เป็นกลไกที่เป็นไปได้สำหรับหน่วยความจำจงใจพ้นที่จัดสรร

ฉันพบสิ่งนี้เป็นสาเหตุของข้อผิดพลาด

สถานที่ที่alloca()มีอันตรายโดยเฉพาะอย่างยิ่งmalloc()เป็นเคอร์เนล - เคอร์เนลของระบบปฏิบัติการทั่วไปมีพื้นที่สแต็กขนาดคงที่ซึ่งกำหนดรหัสฮาร์ดไว้ในส่วนหัวหนึ่ง ไม่มีความยืดหยุ่นเท่ากับสแต็กของแอปพลิเคชัน การโทรติดต่อalloca()ด้วยขนาดที่ไม่ได้รับการรับรองอาจทำให้เคอร์เนลขัดข้อง คอมไพเลอร์บางตัวเตือนการใช้งานalloca()(และแม้กระทั่ง VLA สำหรับเรื่องนั้น) ภายใต้ตัวเลือกบางอย่างที่ควรเปิดในขณะที่คอมไพล์โค้ดเคอร์เนล - ที่นี่จะเป็นการดีกว่าที่จะจัดสรรหน่วยความจำในฮีปที่ไม่คงที่

หากคุณเขียนเกินบล็อกที่จัดสรรโดยไม่ตั้งใจalloca(เนื่องจากบัฟเฟอร์ล้นเช่น) คุณจะเขียนทับที่อยู่ผู้ส่งคืนของฟังก์ชันของคุณเพราะที่อยู่นั้น "เหนือ" ในสแต็กคือหลังจากบล็อกที่จัดสรรของคุณ

ผลที่ตามมาคือสองเท่า:

1. โปรแกรมจะทำงานผิดพลาดอย่างน่าประหลาดใจและเป็นไปไม่ได้ที่จะบอกได้ว่าเหตุใดหรือที่ใดที่มันทำงานผิดพลาด (สแต็กส่วนใหญ่จะคลายที่อยู่แบบสุ่ม

2. มันทำให้บัฟเฟอร์ล้นมากขึ้นหลายเท่าที่เป็นอันตรายเนื่องจากผู้ใช้ที่เป็นอันตรายสามารถสร้างเพย์โหลดพิเศษซึ่งจะถูกวางลงบนสแต็กและสามารถจบการทำงานได้

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

น่าเศร้าที่น่ากลัวอย่างแท้จริงalloca()หายไปจาก tcc ที่น่ากลัวเกือบ GCC alloca()จะมี

1. มันหว่านเมล็ดพืชแห่งการทำลายล้างของมันเอง ด้วยการกลับมาเป็นผู้ทำลายล้าง

2. เช่นเดียวกับmalloc()มันจะส่งคืนตัวชี้ที่ไม่ถูกต้องในความล้มเหลวซึ่งจะ segfault ในระบบที่ทันสมัยด้วย MMU (และหวังว่าจะรีสตาร์ทโดยไม่ต้อง)

3. แตกต่างจากตัวแปรอัตโนมัติคุณสามารถระบุขนาดในขณะใช้งาน

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

หากคุณกดลึกเกินไปคุณจะมั่นใจใน segfault (ถ้าคุณมี MMU)

โปรดทราบว่าmalloc()ไม่มีข้อเสนอเพิ่มเติมเนื่องจากจะส่งคืนค่า NULL (ซึ่งจะแยก segfault หากกำหนดไว้) เมื่อระบบหน่วยความจำไม่เพียงพอ นั่นคือทั้งหมดที่คุณสามารถทำได้คือการประกันตัวหรือเพียงแค่พยายามมอบหมายมัน แต่อย่างใด

เมื่อต้องการใช้malloc()ฉันใช้ globals และกำหนดค่าเป็นศูนย์ หากตัวชี้ไม่ใช่ NULL malloc()ฉันเป็นอิสระก่อนที่จะใช้งาน

คุณสามารถใช้realloc()เป็นกรณีทั่วไปหากต้องการคัดลอกข้อมูลที่มีอยู่ คุณต้องตรวจสอบตัวชี้ก่อนที่จะออกไปทำงานถ้าคุณจะคัดลอกหรือ concatenate realloc()หลังจากที่

3.2.5.2 ข้อดีของการจัดสรร

กระบวนการมีเพียงจำนวน จำกัด ของพื้นที่สแต็คที่มีอยู่ - malloc()ไกลน้อยกว่าจำนวนหน่วยความจำที่มีอยู่เพื่อ

ด้วยการใช้alloca()คุณจะเพิ่มโอกาสในการได้รับข้อผิดพลาด Stack Overflow อย่างมาก (หากคุณโชคดีหรือเกิดข้อผิดพลาดที่อธิบายไม่ได้หากคุณไม่ได้)

ไม่สวยมาก แต่ถ้าประสิทธิภาพมีความสำคัญคุณสามารถจัดสรรพื้นที่บนสแต็กล่วงหน้าได้

ถ้าตอนนี้คุณมีขนาดสูงสุดของหน่วยความจำที่บล็อกความต้องการของคุณและคุณต้องการที่จะเก็บการตรวจสอบมากเกินไปคุณสามารถทำสิ่งที่ชอบ:

void f()
{
    char array_on_stack[ MAX_BYTES_TO_ALLOCATE ];
    SomeType *p = (SomeType *)array;

    (...)
}

ฟังก์ชั่นของ alloca นั้นยอดเยี่ยมและผู้ที่ naysayers ทุกคนกำลังแพร่กระจาย FUD

void foo()
{
    int x = 50000; 
    char array[x];
    char *parray = (char *)alloca(x);
}

Array and Parray นั้นเหมือนกันทุกประการและมีความเสี่ยงเหมือนกันทุกประการ การพูดอย่างใดอย่างหนึ่งดีกว่าตัวเลือกอื่นเป็นตัวเลือกประโยคไม่ใช่ทางเทคนิค

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

ทำไมสิ่งนี้ถึงไม่ดี?

ที่จริงแล้ว alloca ไม่รับประกันว่าจะใช้สแต็ก แท้จริงแล้วการใช้ gcc-2.95 ของจัดสรรจัดสรรหน่วยความจำจากฮีปโดยใช้ malloc เอง นอกจากนี้การติดตั้งใช้งานนั้นอาจนำไปสู่การรั่วไหลของหน่วยความจำและพฤติกรรมที่ไม่คาดคิดหากคุณเรียกมันว่าภายในบล็อกที่มีการใช้งานข้ามไปอีก ไม่ใช่เพื่อบอกว่าคุณไม่ควรใช้มัน แต่บางครั้งก็ทำให้ค่าใช้จ่ายมากกว่าที่จะปลดปล่อย

IMHO ถือเป็นการกระทำที่ไม่ดีเพราะทุกคนกลัวที่จะ จำกัด ขนาดสแต็ก

ฉันได้เรียนรู้มากมายจากการอ่านกระทู้นี้และลิงก์อื่น ๆ :

• /unix/63742/what-is-automatic-stack-expansion
• การ จำกัด การจัดสรรสแต็กสำหรับโปรแกรมบนเครื่อง Linux 32 บิต
• ulimit -s

ฉันใช้ alloca เป็นหลักในการทำให้ไฟล์ C ธรรมดาของฉันสามารถคอมไพล์ได้ใน msvc และ gcc โดยไม่มีการเปลี่ยนแปลงสไตล์ C89 ไม่มี #ifdef _MSC_VER ฯลฯ

ขอบคุณ ! กระทู้นี้ทำให้ฉันสมัครใช้งานเว็บไซต์นี้ :)

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

สำหรับการใช้งานแบบฝังที่มีขนาดสแต็คเป็นที่รู้จักและสามารถกำหนดขีด จำกัด ผ่านการประชุมและการวิเคราะห์เกี่ยวกับขนาดของการจัดสรรและหากคอมไพเลอร์ไม่สามารถอัพเกรดเพื่อรองรับ C99 + การใช้ alloca () ใช้ได้แล้ว รู้จักที่จะใช้มัน

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

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

ความสะดวกในการพกพามีความกังวลน้อยกว่าในพื้นที่ฝังตัวอย่างไรก็ตามเป็นข้อโต้แย้งที่ดีต่อการใช้ alloca () นอกสถานการณ์ที่ควบคุมอย่างระมัดระวัง

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

คำตอบส่วนใหญ่ที่นี่พลาดจุด: มีเหตุผลทำไมใช้ _alloca()อาจเลวร้ายยิ่งกว่าเพียงการจัดเก็บวัตถุขนาดใหญ่ในกอง

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

เปรียบเทียบ:

while (condition) {
    char buffer[0x100]; // Chill.
    /* ... */
}

ด้วย:

while (condition) {
    char* buffer = _alloca(0x100); // Bad!
    /* ... */
}

ปัญหาเกี่ยวกับหลังควรจะชัดเจน

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

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