Hi Bertho,
Two questions about the new parser:
1. Invalid variable names, what's the failure mode?
If the parser encounters a variable name with spaces (or otherwise not
matching [a-zA-Z_][a-zA-Z0-9_]*), will it refuse to start? A silently
dropped axis limit would be dangerous, so I'd expect a hard error,
what's your take?
2. Will we get Inline comments?
Since 2.7.x the parser doesn't support inline comments, VAR = value #
comment treats everything after = as the value. This is a common source
of confusion. Will the new parser support inline comments (e.g. # or ;
after the value)? If so, an escape character (e.g. \# or \;) would be
needed for values that legitimately contain those characters.
Thanks,
Luca
On 3/29/26 7:40 AM, Bertho Stultiens wrote:
Hi all,
The ini-file parser currently accepts spaces in variable names like:
[section]
one var = value
two_var= some thing
It is somehow, somewhat documented in docs/src/config/ini-config.adoc.
However, it is unclear and undocumented what the first variable really
is called and can be one of:
- 'one var'
- ' one var'
- 'one var '
- ' one var '
(note the leading and trailing space).
Using spaces in variable names is IMO very problematic and we all know
how to use underscores (_) I believe. Variables should only contain
letters, digits and underscore and not be allowed to start with a
digit, just like normal identifiers (regex: [a-zA-Z_][a-zA-Z0-9_]*).
As I'm writing a new ini-file parser (mostly done) I'd like to get rid
of the spaces in variable names.
Note that values, that is, all text after the '=', still may contain
spaces and is left and right trimmed (stripped of whitespace). I.e.
variable 'two_var' has value 'some thing' in above example.
This variable name change could be added to the ini-file updater and
fixed if there are any of these spaced variable names. There is work
underway to update INI files to version 1.2 anyway.
A second change I'd like to make is in the way variables are assigned
to sections. Currently, it is allowed to start an ini-file with a
variable that has no section header, like in:
var=no_section_var
[section]
var=[section]var value
You can get to the first 'var' only if you do not specify the section
in the query. However, it is a very bad habit to allow variables to be
outside sections because it only works at the top of the file and what
do they describe? What is the problem of creating a section to
encapsulate them and thereby making variables mandatory subordinates
of a section header? It would be much more logical and consistent to
do so.
Additionally, I'd like to impose the same name restriction to sections
making them standard identifiers, just like variables above. Using the
same section name twice will result in a warning and the contents are
merged.
BTW, the new ini-file parser can be queried to return values as
string, real, signed/unsigned integer (64 bit) and boolean. The parser
does all necessary testing, conversion and error reporting. It
supports different radix conversion for integral numbers with a prefix
(hex: 0x, octal: 0o and binary: 0b) including optional leading +/-
sign in any base. You can also use maps to map strings to values (or
other strings) case sensitive or without case. This is also used
internally to map boolean values. The new parser also handles nested
#INCLUDE statements and no longer needs any includes to be handled and
converted before running the actual LCNC binaries.
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
