This is due to \r being replaced with a space in config_parse_with_offset().
Didn't even know that.. yeah.. ugly ugly... but first time i see it
causing a problem in 20 years.
Also rename them to describe better what they do.
ConfigFile:
cf_filename -> filename
cf_next -> next
cf_entries -> items
ConfigEntry:
ce_fileptr -> file
ce_varlinenum -> line_number
ce_fileposstart -> file_position_start
ce_fileposend -> file_position_end
ce_sectlinenum -> section_linenumber
ce_varname -> name
ce_vardata -> value
ce_cond -> conditional_config
ce_entries -> items
ce_next -> next
ce_prevlevel -> parent
Also add doxygen docs for both structs.
reported in https://bugs.unrealircd.org/view.php?id=5281
It was not removing parts properly if an if didn't match,
leading to a use-after-free bug on-boot (or on rehash).
In the process I renamed config_entry_free to config_entry_free_all
since that is what it does. And I created a new config_entry_free(ce)
to free only 'ce' stuff... which is what we want from the
preprocessor.
that was not supposed to be committed :D
It would also warn about if'd out blocks, which is confusing,
so best to disable the warning altogether for now.
Also, you can escape a $VAR to $$VAR if you really just mean $VAR literally.
Such usage would be very rare though.
Note that the parser is smart enough to know that $var is never a
global variable, it only warns for valid variable names like $VAR and
even then only if it's at the end or has whitespace/dot/comma/etc.
So... false positives should be extremely low...
the variable names to UPPERCASE, digits and underscores (A-Z0-9_).
This makes them easily distinguishable from other items in the conf,
so they don't clash with for example $ip in blacklist::reason.
The @define confusion was reported by Gottem and westor.
Bram Matthys