foamToEnsight crash when patch name > 80 char

in OpenFOAM2.2.1 when using foamToEnsight binary output, if the patch name is equal or greater then 80 characters, it crashes. The crash can be avoided by doing the following modification:

+++ b/applications/utilities/postProcessing/dataConversion/foamToEnsight/ensightBinaryStream.H
@@ -98,7 +98,7 @@ public:
         virtual void write(const char* val)
         {
             char buffer[80] = {0};
-            strcpy(buffer, val);
+            strncpy(buffer, val, 80);
             str_().write(buffer, 80*sizeof(char));
         }

The same crash happens with OpenFOAM-v3.0+. Would it be possible to use the above modification to fix ensightBinaryStream.H?
Thank you

Reassigned to @andy

Thanks @alsdia for reporting the issue.

It was also observed in one of our earlier ticket #92 (closed)

ASCII mode should work in these cases.

@andy @wyldckat Please comment.

Added ~15 label

Interesting... but the strncpy call should perhaps be with 79 and not 80, as documented here: http://www.cplusplus.com/reference/cstring/strncpy/

char * strncpy ( char * destination, const char * source, size_t num );

[...]

No null-character is implicitly appended at the end of destination if source is longer than num. Thus, in this case, destination shall not be considered a null terminated C string (reading it as such would overflow).

But then again, I don't know what the format documentation for Ensight specifies for this, namely if the 80 characters must include the null character or not.

By Bruno Santos on 2016-05-30T23:21:30 (imported from GitLab project)

Thanks Bruno for your comments.

Yes, EnSight has some restrictions about characters (as also observed about % sign in #122 (closed) )

mentioned in commit 9ec62df8b7e8d9474838bac02af2944f4f9ae654

This still seems to be issue

/home/alex4/prashant/SUPPORT/GIT/ID-132-foamToEnsight-binaryFailure/case1

In your case it goes wrong on converting k. 0/k has

inlet
{
    type            fixedValue;
    value           uniform 2.4e+76;
}

In Ensight User Manual (UM-C11, chapter 11.1) it explicitly says the format should be 12.5e so 5 decimal digits precision. Maybe it is just running out of decimal places.

It is not the formatting that is the problem - since it occurs in binary writing. Ensight format does not seem to support double precision numbers (!) so in the converters we convert to single precision and this generates an overflow.

@wyldckat When writing strings: exactly 80 characters for binary. Maximum 79 characters for ascii (+1 for trailing nul).

char buf[80];
strncpy(buf, value, 80); // max 80 chars or padded with nul if smaller

if (format() == IOstream::BINARY)
{
    ...
}
else
{
    buf[79] = 0;  // max 79 in ASCII, ensure it is indeed nul-terminated
    ...
}

@mark

By Bruno Santos on 2016-06-18T14:06:01 (imported from GitLab project)

mentioned in commit 5961431b4a748f855657c21134e9f859bd6cab9e

Status changed to closed by commit 9ec62df8b7e8d9474838bac02af2944f4f9ae654

By Andrew Heather on 2016-06-30T22:09:38 (imported from GitLab project)