2013-06-13 4 views
2

Есть ли какая-либо опасность при отливке типа char * на signed char * в C, где массив символов интерпретируется как массив байтов.cast 'char *' to 'signed char *'

Я читал, что в gcc тип char может быть либо без знака, либо подписан в зависимости от системы. В «худшем» случае char * будет unsigned char *, но поскольку массив просто интерпретируется как серия бит, не имеет значения, идет ли тип от без знака к подписанному.

(Кстати, я проверил другие проводки, но я видел только на вопрос: Re: литейный unsigned char к signed char, и я интересно, если есть что-то уникальное, чтобы просто char Заранее спасибо.).

+0

Я думаю, что это не проблема, если вы используете его как двоичные данные, однако это _is_, если вы интерпретируете его как числовое значение. – legends2k

ответ

4

В самом листе не должно быть никаких проблем, особенно если вы просто интерпретируете массив как байты. В этом случае, хотя я бы предположил, что вы рассматриваете использование типов C99 uint8_t и int8_t, чтобы передать ваши намерения лучше, если они доступны вам.

+1

+1, предлагая использовать правильный тип, чтобы явно показать намерение позади него. – legends2k

+0

Но 'int8_t' может быть недоступен. 'signed char' вполне подходит для намерения« подписанного символа »... –

+0

Я сказал« Если они доступны вам ». Очевидно, что это зависит от вашей среды. Альтернативой, когда они недоступны, было бы использование препроцессора define или 'typedef', чтобы прояснить представление, которое вы хотите использовать для необработанных байтов данных. – Will

2

Нет никакой опасности, прямо разрешено переосмысливать указатели char среди всех трех типов символов, а также переинтерпретировать любой объект указатель объекта как указатель на char (таким образом обрабатывая любой объект как массив байтов).

+2

В самой трансляции нет никакой опасности, но может быть, если какой-то более поздний код зависит от поведения расширений знака того или иного типа. –

+0

@CarlNorum: Конечно, но я полагаю, что у ОП есть причина, по которой она хочет иметь подписанный символ и, следовательно, знает, что ... –

+0

Да, конечно. Я просто хотел поместить его туда. –

1

нет некоторых крайние случаев с сопоставлением после выполнения задания, но и для хранения и передачи к различным функциям, нет нет никакой опасности ...

также в вашем полукоксе реализации может быть подписан или без знака по умолчанию ...

пример проблемы с сопоставлением и знаковости:

на MacOS X с грохотом в c99

char * dog = malloc(1); 
dog[0]= 0xff; 
unsigned char * mansBestFriend = dog; 

if (mansBestFriend[0] > dog[0]) { 
    puts("boy that is strange"); 
} 

выходы: мальчик, что странно

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

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

+0

'sizeof (char)', 'sizeof (signed char)' и 'sizeof (unsigned char)' - все '1'. –

+0

спасибо редактирование .. –

+0

Ваше странное поведение не имеет ничего общего с ABI, либо - только стандартные правила продвижения типа C. –

1

Нет, нет никакой опасности при этом, так как вы хотите использовать его только для своего байтового значения.