Определяю вот такой массив:
extern struct StringPtr {
char * String;
} const __declspec (selectany) Strings [] = {
"xxxxxxxxxxxx",
};
Компилирую с ключом /Gy, в ассемблерном листинге вижу, что Strings объявлен в COMDAT.
Линкую хоть по умолчанию, хоть явно с ключом /opt:ref, в verbose-выдаче вижу:
Discarded "struct StringPtr const * const Strings" (?Strings@@3QBUStringPtr@@B) from main.obj
Смотрю EXE — там лежит строка "xxxxxxxxxxxx".
Наблюдается во всех cl/link с середины 2000-х, и до самых последних версий.
Это глюк компилятора/линкера, или я что-то делаю не так?
Подозреваю, что удаляется массив, а не строки. Конечно, если никто не ссылается на строки, то и они должны удаляться, но.
А
unilink как ведёт себя?
Здравствуйте, flаt, Вы писали:
F>А unilink как ведёт себя?
А где его нынче берут? Ссылка на wiki.dlang.org не работает. Нашел
упоминание на Hex-Rays — там тоже нет ссылок.
doswin32.com вроде обновляется регулярно, но и там unilink лишь упоминается.
Я помню, что много лет назад Харон писал, как устал бороться с link и сделал первый вариант unilink, но так и не сподобился его попробовать.
Здравствуйте, flаt, Вы писали:
F>У меня работает (что даже удивительно, ведь этому FTP уже лет и лет).
У меня этот FTP из Firefox не открывается вообще. Chrome, судя по всему, FTP не умеет — перекидывает на FF. Виндовый ftp.exe устанавливает соединение с сервером, но зависает на командах ls.
Вспомнил, что у меня стоит Opera 12.18 — в ней удалось и открыть, и скачать.
Но при попытке слинковать OBJ в EXE постоянно выдает ошибку "Hash-catalog not accesible". Гугель по такому сообщению (в том числе и с двойным "s") ничего релевантного не выдает.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Сделал багрепорт для MS.
Выяснилось, что удаление таких бесхозных строк можно организовать через /GF (read-only string pooling). Я всю жизнь был уверен, что это работает только на уровне модуля, а оказалось, что /GF генерирует COMDAT, даже если не указан /Oy.
