https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694
Bug ID: 119694
Summary: Excessive getenv uses in cobol FE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: cobol
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
As mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211#c9
the COBOL FE uses getenv in lots of places. I see e.g.
getenv ("ast_add");
getenv ("ast_call");
getenv ("build_symbol_map");
getenv ("cobol_fileline_set");
getenv ("cobol_filename");
getenv ("cobol_lineno_save");
getenv ("field_structure");
getenv ("GCOB_COPYBOOK");
getenv ("GCOBOL_DATA");
getenv ("GCOBOL_TEMPDIR");
getenv ("INDICATOR_COLUMN");
getenv ("initialize_one");
getenv ("initialize_statement");
getenv ("internalize");
getenv ("INTERNALIZE_NO");
getenv ("label_add");
getenv ("LANG");
getenv ("lexio");
getenv ("locally_unique");
getenv ("paragraph_reference");
getenv ("PATH");
getenv ("procedure_definition_add");
getenv ("procedure_reference_add");
getenv ("SHOW_GLOBAL_VARIABLES");
getenv ("SHOW_PARSE");
getenv ("special_pair_cmp");
getenv ("stringify");
getenv ("symbol_field_add");
getenv ("symbol_file_record_sizes");
getenv ("symbol_find_odo");
getenv ("symbol_find_of");
getenv ("symbol_label_add");
getenv ("symbol_special_add");
getenv ("symbols_update");
getenv ("symbol_table_init");
getenv ("symbol_temporaries_free");
getenv ("tmpstring_append");
getenv ("TRACE1");
getenv ("update_block_offsets");
getenv ("update_location");
getenv ("update_yylloc");
getenv ("valid_move");
getenv ("verify_block");
plus a few where getenv is called on something other than string literal, e.g.
static const char * transform_name( const char name[] ) {
uppername_t uname(name);
const char *value = getenv(name);
if( !value ) {
value = getenv(uname.data()); // try uppercase of envar name
if( !value ) value = name; // keep original unmodified
}
return xstrdup(value);
}
Which env vars from these are meant for users in production as opposed to
people just debugging the compiler?
IMHO variables which are meant to be supported (which ideally should be also
documented) should use the same prefix and everything else IMHO should use some
inline wrapper around getenv which will just return NULL unless the compiler
has been configured manually for this kind of debugging. Even then it might be
better if it was just a single variable (say
GCOBOL_DEBUG=update_location,update_yylloc,verify_block), but I think it is
more important to just stop using most of these env vars unless users
explicitly requests that.
