Совместимы ли определения макросов между MIPS и компилятором Intel C.

Question

Кажется, у меня проблема с макросом, который я определил в программе на Си.

Я компилирую это программное обеспечение и успешно запускаю его с помощью компилятора MIPS.

Он строит ОК, но выдает ошибку «Ошибка сегментации» во время выполнения при использовании icc.

Я скомпилировал оба из них на 64-битных архитектурах (MIPS на SGI, с флагом -64 и icc на платформе Intel).

Есть ли какой-то магический переключатель, который мне нужно использовать для правильной работы в обеих системах? Я включил предупреждения для компилятора Intel, и КАЖДЫЕ места в моей программе, где вызывается макрос, выдают предупреждение. Обычно это что-то вроде несоответствующих типов в параметрах макроса (от int до char *) или что-то подобное.

Вот оскорбительный макрос

 #define DEBUG_ENTER(name) {tdepth++; 
 if(tnames[tdepth] == NULL) tnames[tdepth] = memalign(8, sizeof(char)*MAXLEN);
 strcopy(tnames[tdepth],name);
 FU_DEBUG("Entering \n");}

Это в основном используется для отладки - печати в файл журнала с заданным количеством вкладок в зависимости от количества вызовов функций. (tdepth = глубина табуляции)

Я проверил некоторые страницы руководства. похоже, что memalign поддерживается только в IRIX. Это может быть моей проблемой. Я собираюсь выследить это.

Answer 1

Это может быть связано с "порядком байтов" системы. Глядя здесь , кажется, что MIPS имеет переключаемый порядок байтов. Я не уверен, что вы уже используете правильный порядковый номер, но если вы этого не сделаете, у вас точно будут проблемы.

Answer 2

Звучит как массив tnames - это массив int. Если вы назначаете для него указатели, это должен быть массив типа указателя - в этом случае, вероятно, char * подходит.

(Кроме того, strcopy() не является стандартной функцией - вы уверены, что не имеете в виду strcpy()?)

Answer 3

Это может быть проблема порядка байтов. MIPS может быть с прямым порядком байтов, но intel - с прямым порядком байтов.