public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Kevin Ryde <user42@zip.com.au> To: gcc-gnats@gcc.gnu.org Subject: c/10260: alloca 0xFFFFFFFF and -fstack-check Date: Sat, 29 Mar 2003 00:56:00 -0000 [thread overview] Message-ID: <87y92zqafy.fsf@zip.com.au> (raw) >Number: 10260 >Category: c >Synopsis: alloca 0xFFFFFFFF and -fstack-check >Confidential: no >Severity: non-critical >Priority: low >Responsible: unassigned >State: open >Class: wrong-code >Submitter-Id: net >Arrival-Date: Sat Mar 29 00:36:00 UTC 2003 >Closed-Date: >Last-Modified: >Originator: >Release: 3.2.1 20020830 (Debian prerelease) (Debian testing/unstable) >Organization: >Environment: System: Linux blah 2.2.15 #1 Tue Apr 25 17:13:48 EST 2000 i586 unknown Architecture: i586 <machine, os, target, libraries (multiple lines)> host: i386-pc-linux-gnu build: i386-pc-linux-gnu target: i386-pc-linux-gnu configured with: /mnt/data/gcc-3.1/gcc-3.2-3.2.1ds0/src/configure -v --enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit --enable-java-gc=boehm --enable-objc-gc i386-linux >Description: When a program attempts to alloca 0xFFFFFFFF bytes under -fstack-check, a stack overflow exception is not provoked. >How-To-Repeat: The program foo.c below compiled and run gcc -fstack-check foo.c ./a.out successfully reaches and executes the printf, whereas I had hoped it would get a segv, which is what happens when a smaller alloca amount like 0xFFFF0000 is requested. Looking at the code generated I guess a size like 0xFFFFFFFF is rounded up to a multiple of the stack alignment, giving 0. And the 4392 byte safety margin makes sizes like 0xFFFFFF00 wrap around to smallish positive values too. In normal circumstances I wouldn't think this is a problem, since anyone asking for such sizes deserves everything they get, but when -fstack-check is in use I think it'd be highly desirable to ensure a system stack overflow is provoked for any size bigger than the system can handle. The same seems to be true of -fstack-limit-symbol (in the current gcc cvs), but only in respect of the rounding up, so 0xFFFFFFFF is not detected as an overflow, but sizes up to 0xFFFFFFF0 are. --=-=-= Content-Type: text/x-csrc Content-Disposition: attachment; filename=foo.c volatile unsigned n = 0xFFFFFFFF; int main (void) { char *p; p = __builtin_alloca (n); printf ("%p\n", p); } --=-=-=-- >Fix: >Release-Note: >Audit-Trail: >Unformatted: --=-=-=
next reply other threads:[~2003-03-29 0:36 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-03-29 0:56 Kevin Ryde [this message] 2003-05-10 20:16 Dara Hazeghi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87y92zqafy.fsf@zip.com.au \ --to=user42@zip.com.au \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).