From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,88c97d669795535a X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: What task storage_size to use? Date: 1997/11/24 Message-ID: #1/1 X-Deja-AN: 292377108 References: <3472A748.213DF2CA@intermetrics.com> <3.0.1.32.19971121191820.00b96cf0@spectre.mitre.org> <34785EC5.740B76B0@intermetrics.com> <3479C8CF.9F2FEA18@intermetrics.com> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 880419710 31274 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1997-11-24T00:00:00+00:00 List-Id: Michael said <> Well 3.07 is indeed truly ancient at this stage, and indeed, on some targets, lacked stack overflow checking, but the current version of GNAT supports stack overflow checking. The algorithm used by GNAT allows for a stack buffer space which is guaranteed available when a storage error is signalled. You can trivially adjust this buffer size to meet your needs, and just set the global variable in a storage error handler (actually it had better NOT be a global variable, but rather a task specific one, use task_Attributes if necessary).