IFC file with single backslash in STRING (HEADER:FILENAME) fails to load.

[santiagoIT]

The IFC file contains the following string:

FILE_NAME('C:\Users\1PIPEIFC.IFC','2012-01-01T09:00:00',('User'),('A',''),'v3','W','');

that string is not properly encoded. Correct would be:

FILE_NAME('C:\Users\1PIPEIFC.IFC','2012-01-01T09:00:00',('User'),('A',''),'v3','W','');

In https://www.steptools.com/stds/step/IS_final_p21e3.html#clause-6-4-3 I found the following:
1PIPEIFC.zip

The latest version of Xbim Xplorer cannot open the IFC file and reports the following:

which is not really helpful. I had to debug the xBim Essentials code to figure out what the issue is.

If an issue parsing a string occurs we should at least report the line, column number so the issue can be identified.

Would be willing to assist in implementing this if someone can guide me as to where to do this.

Thank you!

[santiagoIT]

Small remark,
xBim Xplorer 4.0 is able to open the file just fine.
But if I compile the latest xBim Xplorer version, it can no longer open the file

[martin1cerny]

Thank you for going this far @santiagoIT. Can you create a simple code test please? I'm happy to point you to the right direction.

[santiagoIT]

@martin1cerny
I added a unit test to my fork:

santiagoIT@3bc7af1

Thank you!

If you guide me in the right direction will be happy to contribute!

[martin1cerny]

This will likely require a change deep down in the scanner. That means you need to change the lexer file and re-run the scanner code generation. Let me know if lex/yacc is not your field.

[santiagoIT]

I moved the test to a different branch so that it is excluded from an open pull request.
santiagoIT@4cebc02

No, I am not familiar with lex/yacc (I do know what they are) but have never used them. But am always open to learn.

[andyward]

If we do this we'll need to fix GPLEX's support for large files or re-apply: 6517bc1

[CBenghi]

Martin and I have had a conversation about this quite some time ago... and the memory is fading around the details of the matter.

The problem is that I could not find a way to tolerate this type of mistakes in the file, while adequately reading well formed files that use the backslash for short unicode encoding e.g. if memory serves me well something like

\S\'

which is a valid sequence for a character (non terminating), I don't remember what it maps to.
I'm not sure if GPLEX can be persuaded to recover from such type of error in the header.