SORT C всегда перемещает первый элемент массива в конец

Question

У меня есть символьная переменная, которая содержит список строк с разделителями, например:

data lists;

format list_val $75.;
list_val = "PDC; QRS; OLN; ABC";
run;

Мне нужно расположить элементы каждого списка в алфавитном порядке (так что желаемый результат при применении к указанной выше строке это "ABC; OLN; PDC; QRS;").

Я адаптировал решение здесь для своих целей следующим образом:

data lists_sorted;

set lists;

array_size = count(list_val,";") + 1; /* Cannot be used as array length must be specified at creation */

array t(50) $ 8 _TEMPORARY_;

call missing(of t(*));

do _n_=1 to array_size;

t(_n_)=scan(list_val,_n_,";");

end;

call sortc(of t(*));

new_list_val =catx("; ", of t(*));

put "original: " list_val " new: " new_list_val;
run;

Когда я запускаю этот код, я получаю следующий результат:

original: PDC; QRS; OLN; ABC new: ABC; OLN; QRS; PDC

Чего нельзя было ни ожидать, ни желать. В общем, результатом применения вышеуказанного кода к любому списку является новый список, отсортированный по алфавиту, за исключением того, что первый элемент исходного списка становится последним элементом нового списка, независимо от его алфавитного порядка.

Я не могу найти в документации к sort c ничего, что могло бы объяснить такое поведение, поэтому мне интересно, связана ли проблема с тем, как я настроил временный массив (я не имею большого опыта работы с ними). ​​

Кто-нибудь знает, почему sort c так себя ведет? Дополнительный вопрос: могу ли я динамически определять размер массива вместо жесткого кодирования такого значения, как 50?

Answer 1

Это потому, что вы включили ведущие пробелы при присвоении значений элементам массива. Удалите их.

t[_n_]=left(scan(list_val,_n_,";"));

Если вы хотите знать, какой массив минимального размера вы можете использовать для своего шага данных, вам нужно будет обработать набор данных дважды.

proc sql ;
  select max(count(list_val,";") + 1) into :max_size trimmed from have;
quit;
....
array t[&max_size] $ 8 _temporary_;

Но есть вероятно, не будет большого вреда просто использовать какое-то большое постоянное значение.