public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "zack at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/14438] [3.5, needs investigation] -E of #pragma has negative line number Date: Wed, 24 Mar 2004 04:59:00 -0000 [thread overview] Message-ID: <20040324045907.8285.qmail@sources.redhat.com> (raw) In-Reply-To: <20040305002353.14438.lindsayd@cisco.com> ------- Additional Comments From zack at codesourcery dot com 2004-03-24 04:58 ------- Subject: Re: preprocessor/14438 Alexandre Oliva <aoliva@redhat.com> writes: > The reason why the patch had introduced a regression was that > pfile->cur_token pointed to uninitialized memory, one past the last > initialized token. _cpp_lex_direct() doesn't skip to the next line > because we're processing a directive, so it just sets result->type to > CPP_EOF, along with its correct location, after incrementing > pfile->cur_token past result, without any form of initialization to > this value. In fact, I'm a bit concerned as to what might happen if > we were to call _cpp_lex_direct() an unlimited number of times while > processing a directive; I don't see anything that would prevent > cur_token from running past the memory area reserved for it. Oh, ugh. > I suppose one way to fix this issue would be to decrement cur_token > again when returning in the CPP_EOF case, such that we'd return the > same EOF token over and over; another would be to just refrain from > dereferencing cur_token after reading an EOF token, but how would we > tell? And, more importantly, why would we want to? Clearly we don't > need it in the case I thought we did when I added the code I just > removed; I don't think we need it elsewhere. Suggest you add defensive code to prevent running cur_token off the end of the buffer, as you suggest, and then go ahead and close the bug report. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14438
next prev parent reply other threads:[~2004-03-24 4:59 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-03-05 0:23 [Bug preprocessor/14438] New: -E of #pragma poison " lindsayd at cisco dot com 2004-03-05 8:20 ` [Bug preprocessor/14438] [3.4/3.5 Regression] " pinskia at gcc dot gnu dot org 2004-03-10 16:22 ` [Bug preprocessor/14438] [3.3/3.4/3.5 Regression] -E of #pragma " reichelt at gcc dot gnu dot org 2004-03-11 6:55 ` aoliva at gcc dot gnu dot org 2004-03-20 21:17 ` reichelt at gcc dot gnu dot org 2004-03-21 20:16 ` zack at gcc dot gnu dot org 2004-03-21 20:18 ` mmitchel at gcc dot gnu dot org 2004-03-21 22:11 ` gdr at integrable-solutions dot net 2004-03-23 0:45 ` aoliva at gcc dot gnu dot org 2004-03-23 0:55 ` lindsayd at cisco dot com 2004-03-23 1:13 ` aoliva at gcc dot gnu dot org 2004-03-24 3:18 ` cvs-commit at gcc dot gnu dot org 2004-03-24 3:19 ` cvs-commit at gcc dot gnu dot org 2004-03-24 3:19 ` cvs-commit at gcc dot gnu dot org 2004-03-24 3:27 ` [Bug preprocessor/14438] [3.5, needs investigation] " aoliva at gcc dot gnu dot org 2004-03-24 4:31 ` aoliva at redhat dot com 2004-03-24 4:36 ` neroden at gcc dot gnu dot org 2004-03-24 4:59 ` zack at codesourcery dot com [this message] 2004-03-30 21:59 ` aoliva at redhat dot com 2004-03-31 0:07 ` [Bug preprocessor/14438] Potential need for buffer overflow checks in _cpp_lex_direct zack at gcc dot gnu dot org 2004-03-31 0:08 ` zack at gcc dot gnu dot org 2004-03-31 0:09 ` zack at gcc dot gnu dot org 2005-04-21 5:06 ` mmitchel at gcc dot gnu dot org 2005-07-05 2:14 ` pinskia at gcc dot gnu dot org 2005-07-08 1:44 ` mmitchel at gcc dot gnu dot org 2005-09-10 5:58 ` pinskia at gcc dot gnu dot org
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=20040324045907.8285.qmail@sources.redhat.com \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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).