Parsing of value silently fails: oops
Attempting to write a regex into a FHiCL parameter, I found that the FHiCL parser "silently" replaces the value which failed parsing with
For example, a FHiCL file with content:
pattern: "$\d+^"is seen by
Policy is 1; path is "FHICL_FILE_PATH" pattern: "$\d+^"but
fhicl-dumpshows it as
# Produced from 'fhicl-dump' using: # Input : pattern.fcl # Policy : cet::filepath_maker # Path : "FHICL_FILE_PATH" pattern: oops
I would rather see the parser throw an exception in these cases.
(I am sure there is a way to correctly escape these strings... I ended up being more standard and using
[[:digit:]] instead of
\d, which is just as good.)
#4 Updated by Kyle Knoepfel about 2 months ago
- % Done changed from 0 to 100
- Status changed from Assigned to Resolved
This bug has been fixed with commit fhicl-cpp:541160c. Using your sample configuration, the exception thrown now looks like:
$ fhicl-dump test.fcl ---- Parse error BEGIN The string "$\d+^" is not representable as a canonical string. It is likely you have an unescaped (or incorrectly escaped) character. ---- Parse error END
And indeed, if you were to use the single-quoted string (
'$\d+^'), or the double-escaped
'd' within the double-quoted string (
"$\\d+^"), you would get what you want. Incidentally, assuming this represents a regular expression, the
$ characters should probably be reversed.
#5 Updated by Gianluca Petrillo about 2 months ago
Kyle Knoepfel wrote:
Incidentally, assuming this represents a regular expression, the
$characters should probably be reversed.
I consistently confuse
$. Kind of a branding thing for me; for the rest of the people, though... yes, they should really swap them.