Bug #23656
Parsing of value silently fails: oops
Description
Attempting to write a regex into a FHiCL parameter, I found that the FHiCL parser "silently" replaces the value which failed parsing with "oops"
.
For example, a FHiCL file with content:
pattern: "$\d+^"is seen by
fhicl-expand
like:Policy is 1; path is "FHICL_FILE_PATH" pattern: "$\d+^"but
fhicl-dump
shows 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.)
Associated revisions
History
#1 Updated by Kyle Knoepfel about 1 year ago
- Status changed from New to Feedback
Seems to be a bug. Have you tried this with an actual art job, and you still get the "oops" problem?
#2 Updated by Gianluca Petrillo about 1 year ago
Yes. That was, in fact, the context in which I encountered the issue.
#3 Updated by Kyle Knoepfel 8 months ago
- Target version set to 3.06.00
- Assignee set to Kyle Knoepfel
- Status changed from Feedback to Assigned
#4 Updated by Kyle Knoepfel 8 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 ^
and $
characters should probably be reversed.
#5 Updated by Gianluca Petrillo 8 months ago
Kyle Knoepfel wrote:
Incidentally, assuming this represents a regular expression, the
^
and$
characters should probably be reversed.
I consistently confuse ^
and $
. Kind of a branding thing for me; for the rest of the people, though... yes, they should really swap them.
#6 Updated by Kyle Knoepfel 7 months ago
- Status changed from Resolved to Closed
Resolve issue #23656: Do not silently fail on malformed string.