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


  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: link
Be 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).