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]

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


Aehm, sorry., 

again, with patch files.


>
> 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.
>
 		 	   		  

Attachment: changelog-pr58893.txt
Description: Text document

Attachment: patch-pr58893.diff
Description: Binary data


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