STEP Reader - files with double points in float values can't be properly imported

Branch [archived branch] has been created by Author.

[revision removed]


This branch includes the following new commits:

       new 532f325 0025170: Fix the incorrect parsed float values with two points


Detailed log of new commits:

[revision removed]
Author: razmyslovich
Date: Wed Aug 20 11:57:17 2014 +0200

    0025170: Fix the incorrect parsed float values with two points

The fix is provided, please, review it

Hello Dmitry, could you please confirm that this problem (diplicate points in floating point values) is systematically found in STEP files produced by CATIA V5R19SP6?

This seems to be quite strange, as we normally can expect problems related to semantic or some syntax errors in the file, but not on the level of floating-point number representation! I have serious doubt if treatment of such errors makes sense. If this is systematic for CATIA, do you know if other systems can read such files successfully?

Hello, Andrey, unfortunately, I can't confirm, that the problem can be systematically reproduced, since I have just 2 STEP files generated by CATIA V5R19SP6 in my database. I have no license for CATIA. And all our customers use native CATIA files import since the last version of our software.
Do you think, it's dangerous to integrate the fix provided?

Hello Dmitry, no I do not think that fix will be dangerous, even if it is always possible to have some unpredictable effects. I rather think that it might be useless if this situation appeared only once in single file, e.g. due to data transfer error. Can you confirm that this problem appears systematically (i.e. in all or many floating point numbers) at least in both data files you have? Another question is whether your fix allows obtaining correct result (i.e. can you check that two points should be considered as one? or maybe second point should be interpreted as 0?).

Hello, Andrey. I've checked once again all my STEP files generated by CATIA V5 and it seems that it was problem exactly in R19SP6, since neither other releases nor other service packs have something to do with it. Moreover, analyzing the files, generated by R19SP6 I found out, that this problem appears many times in the file, BUT it appears not only in the float values. It seems, that the second dot appears randomly near another dot. For example, the files are full of the following entity parameters: ".UNSPECIFIED..", ".F..", ".U.." and float values. But only float values can't be correctly parsed.
And especially for these files my fix seems to produce the correct result, since the geometry looks fine and the customer hasn't reported further problems with files after this fix.
I have also tried some other STEP software: IDA-STEP, STP Viewer, HOOPS Exchange Demo. Only HOOPS can correctly parse the file, all other detect an error.
So, I agree, that this fix is most probably irrelevant, since it appears only for CATIA V5R19SP6 (moreover we aren't sure if it appears consistently even for this CATIA version). But maybe it's reasonable to generate a parse error rather then proceed with wrong float value?

Hello Dmitry, thank you for details and sorry for delay with my answer.. I have checked the situation with Hoops Exchange Demo and in my understanding its behavior is more like in current OCCT, i.e. it reads the number only until the second dot and does not report error. Thus the change you proposed seems to be not in line with behavior of other translators, so I am not in favor of taking it. I will try to check this more in depth a later, then we decide.

Hello, Andrey. I disagree, that current OCCT behaves similar to HOOPS, please, check the screenshots I uploaded.

Current version of OCCT (after fix #0029399) uses different implementation of function Fastof() / Strtod() that provides fast reading of real values. Thus original patch is not applicable any more. The patch is attached for archiving purposes, to be applied on top of [revision removed]

There seem to be no reason to hack such a low-level function (with quite possible side effects) for handling so much specific and rare situation which is clearly a bug in the software that generated STEP file. If necessary, such files can be pre-processed before reading to remove double dots (this can be done even on the fly using stream interface available since #0027342).

Thus I am closing the issue.

It can be reconsidered indeed if evidence is provided that the problem is commonly reproduced for different users / projects.

Branch [archived branch] has been deleted by Participant.

[revision removed]