Hi!
Just noticed there's a bug in the format parser when writing SAS xport files.
xport_write_variables is using sscanf to pull the format name, width and decimals:
|
sscanf(variable->format, "%s%d.%d", name, &width, &decimals); |
Because there are no spaces between the name and the other bits the whole string is being consumed as the format name by %s, and width and decimals are never set. In many cases this is still interpreted correctly from the name alone, but others have issues, for e.g.:
- COMMA10.3 - longer than 8 chars, so is cut off when storing the format name
- 10.3 - fails with an invalid name warning in SAS
It seems like a bit of a pain to parse - the format is <name><width>.<decimal>, but width and decimal and the period between them are all optional. Name follows the SAS naming rules, with the additional requirement that it can't end in a number.
Hi!
Just noticed there's a bug in the format parser when writing SAS xport files.
xport_write_variablesis usingsscanfto pull the format name, width and decimals:ReadStat/src/sas/readstat_xport_write.c
Line 114 in f8731f8
Because there are no spaces between the name and the other bits the whole string is being consumed as the format name by
%s, and width and decimals are never set. In many cases this is still interpreted correctly from the name alone, but others have issues, for e.g.:It seems like a bit of a pain to parse - the format is
<name><width>.<decimal>, but width and decimal and the period between them are all optional. Name follows the SAS naming rules, with the additional requirement that it can't end in a number.