Портирование библиотеки IAR -> GCC, Проблема с определением типа wchar_t Опции

[Слёзкин]

Здравствуйте!

Обращаюсь с просьбой посодействовать по следующему вопросу.
Существует файл статической библиотеки <filename.a> и header-файл <filename.h>, где объявлены типы и функции.
Исходный код библиотеки разработчик предпочел скрыть и предоставил .a -файл, скомпилированый в IAR.

Моя же задача - правильно сцепить данную библиотеку с моим проектом, компилируемым с помощью GCC. Однако, линковщик предупреждает о возможных ошибках в работе программы из-за несовместимости типов wchar_t. Мне удалось выяснить что в среде Windows этот символьный тип имеет размер в 2 байта, а в Linux - целых 4.

Возникло два вопроса.

1) Нужно ли обращать внимание на этот warning? Ведь размер wchar_t в стандартных библиотеках компилятора GCC больше, чем в рассматриваемой. И в первом приближении кажется, что потери данных произойти не может (исключая случай с переполнением возвращаемых в код библиотеки переменных).

2) Если ответ на первый вопрос - нужно. В подпрограмме ReadELF можно просматривать имена функций библиотеки. А можно ли каким-нибудь образом узнать типы входных и выходных параметров этих функций? Ведь линковщик как-то понимает, что это ни что иное, как wchar_t!

Большое спасибо!

[Aaron]

дак если есть <filename.h>, там же имена и параметры передаваемые/возвращаемые указаны. насчёт 2/4 байта - результаты могут быть плачевные, если в функциях идёт дополнительное преобразование типов.

[Слёзкин]

дак если есть <filename.h>, там же имена и параметры передаваемые/возвращаемые указаны. насчёт 2/4 байта - результаты могут быть плачевные, если в функциях идёт дополнительное преобразование типов.

В .h объявлены (увы) только пользовательские функции... Среди них ни одна не равна и не имеет в качестве аргумента wchar_t...

Да.
Если допустить, что четырехбайтный wchar_t это unsigned long int, а двухбайтный- unsigned int, то мой вопрос можно записать так:

Код

unsigned long A;
unsigned B;
B=0x1234;
A=B; // Чему будет равно A? 0x00001234 или 0x????1234
A=0x12345678;
B=A; // Ну здесь наверное B=0x5678? Тоже ведь не факт

p.s. Про такое, как флаг -fshort wchar и макрос __WCHAR_MAX__ я читал, но задействие сих может окончится печально при работе других стандартных библиотек...

[Слёзкин]

А может быть, кто-то имеет достаточный опыт, чтобы ответить на вопрос, или высказать соображения: возможно ли вообще использовать библиотеку, скомпилированную в IAR для проекта, компилируемого GCC?
Или, быть может, по каким-то причинам, это заведомо невозможно?

Сообщение отредактировал Слёзкин - Nov 1 2011, 08:26

[demiurg_spb]

Может было бы и возможно если оба компилятора удовлетворяли одному abi-eabi.
Мне думается, что вряд-ли это так...

[RCray]

Может было бы и возможно если оба компилятора удовлетворяли одному abi-eabi.
Мне думается, что вряд-ли это так...

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

[demiurg_spb]

EABI в данном случае относится к архитектуре процессора?
Тогда компиляторы последней версии по идее должны поддерживать этот EABI.

Моё мнение, что компиляторы не особо что-то кому-то должны. Они просто соответствую и говорят об этом либо нет, что тоже вполне возможно.