psMetadataConfigFormat does not handle arbitrary length input

[eugene]

psMetadataConfigFormat uses fixed length strings for the individual lines (so-so
proble) and the total output string (big problem). this crashed writing the
header read in by a psFitsReadHeader (not surprising: the output string was
limited to 16000 chars, and the sample header I tried was 35000 chars...)

In exploring this bug, I took a close look at psMetadataConfigFormat, and it is
a bit of a mess:

• would not need fixed length strings if it used psStringAppend instead of snprintf

• does not make good use of local temporary variables for readabilty (eg, lots

of repeated entries like ((psTime*)(item->data.V))->... instead of writing
psTime *time = item->data.V once and referring to time)

• In the vector output section, the values are written until a zero-value entry

is reached, as if the vectors were zero-value terminated!

• the nested psMetadataConfigFormat call needs to handle a possible NULL return

value and return NULL (implied error in the lower level)

• errors are causing memory leaks

• the first block of code is fairly bizarre. I paste it here without further

comment:

type = item->type;
if ( type == PS_DATA_STRING) {

type = PS_DATA_STRING;

}
if ( type == PS_DATA_VECTOR) {

type = PS_DATA_VECTOR;

}
if ( type == PS_DATA_TIME) {

type = PS_DATA_TIME;

}
if ( item->type == PS_DATA_METADATA) {

type = PS_DATA_METADATA;

}
if (item == NULL) {

type = PS_DATA_UNKNOWN;

}

I have cleaned up this code and I will add it as an attachment

[eugene]

cleanup of psMetadataConfigFormat

[David.Robbins@…]

Sorry about this one. Not sure what happened here. Only thought is that
multiple copies must have been confused before checking in to CVS. Anyway, I
merged the clean-up in and did some of my own cleanup too. (ie, added some
missing error checks, etc.) Looks good now.