This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Fix PR preprocessor/58893 access to uninitialized memory
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Cc: Jeff Law <law at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Fri, 26 Sep 2014 14:16:05 +0200
- Subject: [PATCH] Fix PR preprocessor/58893 access to uninitialized memory
- Authentication-results: sourceware.org; auth=none
Hi,
this patch fixes PR58893, which is an access to uninitialized memory, which may or may not crash in
linemap_resolve_location, or just print error messages with bogus location.
When the first -include file is processed we have the case, where
pfile->cur_token == pfile->cur_run->base, this is directly called
by the front end. However in the case of the second -include file,
this is called from _cpp_lex_token -> _cpp_get_fresh_line ->
cpp_push_include, with pfile->cur_token != pfile->cur_run->base,
and pfile->cur_token[-1].src_loc and token not (yet) initialized.
The problem is, when the include file cannot be found, we need
src_loc to be initialized to some safe value: 0 means UNKNOWN_LOCATION.
Regarding the hunk in cpp_diagnostic, which is not directly involved
in this bug, but it is still obviously wrong:
The line "src_loc = pfile->cur_run->prev->limit->src_loc"
is probably unreachable, but will crash it is ever executed.
see:
_cpp_init_tokenrun (tokenrun *run, unsigned int count)
{
run->base = XNEWVEC (cpp_token, count);
run->limit = run->base + count;
run->next = NULL;
}
so, limit points at the end of the run.
Boot-Strapped and Regression-tested on x86_64-linux-gnu
Ok for trunk?
Thanks
Bernd.