https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
Robert Dubner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #11 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:711c10383f494b316c5919aa0141f6fa609578b4
commit r15-9392-g711c10383f494b316c5919aa0141f6fa609578b4
Author: Bob Dubner
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
Simon Sobisch changed:
What|Removed |Added
CC||simonsobisch at gnu dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #10 from Sam James ---
Dunno if it'd be an issue if for some reason we had a suid COBOL program? (In
general though, I agree, it's more of a documentation issue and the other
issues jakub mentions, not a security one.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #8 from Jakub Jelinek ---
I meant it the other way around, keep the getenv calls that should work for all
users, maintainers or not in the 15 release as is.
Rename all other getenv calls (those which are meant for maintainer debuggin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #7 from Robert Dubner ---
There are only a few getenv() calls that I regard as necessary. Those can be
renamed. As I said, GCOBOL_SHOW and GCOBOL_TRACE. There is a COBPATH that
operates like LD_LIBRARY_PATH; that can, and should,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #6 from Jakub Jelinek ---
I'm not sure there is enough time before the branching for new options etc.
So, I just wondered about something that can be done quickly, whether it is
renaming
most of the getenv uses (except for those whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #5 from Robert Dubner ---
As the parser parses each COBOL statement, it tends to call a function,
generally named parser_whatever. For example, the COBOL statement "OPEN INPUT
" results in the function parser_file_open() being call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #4 from Jakub Jelinek ---
Note, if SHOW_PARSE is something like dumping the semantic IL, then the usual
way is have a compiler option and dump the details into a file.
Either as messages into the -fdump-tree-original file or see e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
Robert Dubner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
--- Comment #2 from Richard Biener ---
getenv is also not the cheapest thing to do, so I'd at least put it behind a
debug option (or param?).
So for now, amend the existing -f{flex,trace,yacc}-debug flags with
a -fextra-debug flag and replace t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
12 matches
Mail list logo
