This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] Fix PR preprocessor/58893 access to uninitialized memory


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.
 		 	   		  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]