Fix segmentation fault when trying to save invalid long strings

[simon-ess]

This can occur if you have something like the following:

record(waveform, "foo") {
  field(FTVL, "CHAR")
  field(NELM, "10")
  info(autosaveFields, "VAL VAL$")
}

The VAL$ field will cause a segmentation fault when it tries to save it to disk. The reason this seems to happen is that on one hand, VAL$ is regarded by autosave as a valid field (it is a field, but with a $ at the end). On the other hand, when connecting a monitor, the connection fails as the VAL field is not of the correcct type as defined in dbChannelCreate from EPICS base.

This means that autosave will try to save the date from an unconnected array, with uninitialised pArray, causing a segmentation fault.

Fixes #59

[anjohnson]

I'd recommend testing this change against the lsi & lso (long string in/out) record types too, they provide access to the VAL field slightly differently than a waveform record although I doubt the code would need to be any different for them. Using these types instead of a CHAR waveform makes the database designer's intention clearer when they're available (since Base 3.15).

[simon-ess]

@anjohnson - Having just picked up this ball that I dropped quite a while ago, I can report the following:

• lsi records save in "the same way" as before with this change, in the sense that the exact same data is saved; however in neither case is the long string actually saved. That is, if you have

record(lsi, "lsi") {
    field(SIZV, "70")
    field(INP,  {"const": "0xxxxxxxx1xxxxxxxx2xxxxxxxx3xxxxxxxx4xxxxxxxx5xxxxxxx"})
    info(autosaveFields, "VAL VAL$")
}

then both before and after this change the saved value is identical: that is, it is a truncated version of the above string, truncated at 39 characters. The only difference is that before this change we save both lsi.VAL and lsi.VAL$ (with the exact same value), whereas after we only save lsi.VAL (with of course the same value).

So this change:

• slightly modifies autosave for lsi records, but not in a way that affects behaviour
• fixes a segfault for waveform records

[anjohnson]

Is there any connection between this and the new PR #73 from SLAC? The subject matter feels similar, but the change is in a different area of the code. There are now conflicts in this branch, so while looking at them could you also take a look at that PR too?

[simon-ess]

I have pushed to fix the conflicts, which were formatting ones from #66. However, I should note that the segfault was actually fixed by #67.

The MR #73 does not actually address the issue at hand, either before or after #67. These are independent of each other.