Project

General

Profile

Bug #23656

Parsing of value silently fails: oops

Added by Gianluca Petrillo 8 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Kyle Knoepfel
Target version:
art - 3.06.00
Start date:
11/26/2019
Due date:
% Done:

100%

Estimated time:
Spent time:
2.00 h
Duration:

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

Revision 541160c5 (diff)
Added by Kyle Knoepfel about 2 months ago

Resolve issue #23656: Do not silently fail on malformed string.

History

#1 Updated by Kyle Knoepfel 7 months 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 7 months ago

Yes. That was, in fact, the context in which I encountered the issue.

#3 Updated by Kyle Knoepfel about 2 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 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 ^ and $ 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 ^ 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.

Also available in: Atom PDF