2016-02-08 3 views
2

У меня есть API, который реализует операцию записи в EEPROM. Вот его заявление:Преобразование между uint8 и char в C

CYBLE_API_RESULT_T CyBle_StoreAppData (uint8 * srcBuff, const uint8 destAddr[], uint32 buffLen, uint8 isForceWrite); 

Это работает хорошо, когда я называю эту функцию и отправить параметр массива в srcBuff, который был объявлен как uint8 типа.

Проблема в том, что мне нужно отправить указатель на массив char. Я думал, что char уже является uint8, но я получаю предупреждение о компиляторе, если я отправлю указатель на массив char этой функции вместо uint8. Почему я не могу использовать char вместо uint8? Вот 2 примера вызова этой функции:

static const uint8  datastack_ROM[dedicatedRomSize] = {0}; 
uint8     Container_ID[10]; 
char     Prefix[10]; 

//Call the function with Container_ID which has been declared as uint8. This is working. 
CyBle_StoreAppData(Container_ID,datastack_ROM,10,0); 

//Call the function with Prefix which has been declared as char. This is NOT working. 
CyBle_StoreAppData(Prefix,datastack_ROM,10,0); 

Вот предупреждение для второго вызова:

passing char[10] to parameter of type 'uint8 *' converts between pointers to integer types with different sign.

ли не char и uint8 же?

+1

Важная вещь в сообщении об ошибке - это часть о «другом знаке». Это означает, что ваш 'char' тип' signed', тогда как 'uint8' (предполагается здесь)' unsigned'. Вероятно, это не будет большой проблемой, поэтому вы должны просто указать свой указатель: 'CyBle_StoreAppData ((uint8 *) Prefix, ...)' –

+0

Это похоже на нарушение ограничений, остерегайтесь: http: // stackoverflow.com/questions/30535814/pass-unsigned-char-pointer-to-atoi-without-cast –

+0

@GiorgiMoniava Я искал похожие вопросы, но, думаю, я не мог этого найти. Как я могу упомянуть, что есть аналогичный вопрос? Или мне это нужно? –

ответ

1

Оба типа имеют длину 8 бит. Разница связана с подписью.

  • Тип uint8 не обозначен.
  • Тип char должен быть подписан в вашем случае. На самом деле это зависит от компилятора, но большинство компиляторов считают тип char подписанным по умолчанию и имеют возможность принудительно принудительно вводить char в качестве неподписанных. Смотрите C99 standard document reference §6.2.5p15:

Реализация определяет символ, чтобы иметь один и тот же диапазон, представление и поведение, либо подписанного полукокса или неподписанные символ.

CHAR_MIN, определенный в limits.h, будет иметь одно из значений 0 или SCHAR_MIN, и это можно использовать для различения двух параметров.

+0

Я не думал, что это зависит от компилятора. Я нашел эту ссылку [link] (https://developer.mbed.org/handbook/C-Data-Types). Но если я объявляю 'Container_ID' как unsigned, я не могу использовать функцию строки, которую я использую для другого задания. Так что я должен бросить его, как на ответ @ Joachim? –

+0

См. Мое редактирование, я добавил ссылку на стандарт C. Но да, вы могли бы использовать его, как было предложено. – greydet

+0

Спасибо :) Это было объяснительно. Я подтвердил, что мой компилятор считал это подписанным. Поэтому я использовал операцию литья, и она работает очень хорошо. Спасибо вам всем. –

0

uint8_t, скорее всего, определяется как символ без знака.

char это собственный тип, который ведет себя точно так же, как подписанный символ char или unsigned char (обратите внимание, что это три разных типа).

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

+0

Я не думал, что это зависит от компилятора. Я нашел эту ссылку [link] (https://developer.mbed.org/handbook/C-Data-Types). Но если я объявляю 'Container_ID' как unsigned, я не могу использовать функцию строки, которую я использую для другого задания. Так что я должен бросить его, как на ответ @ Joachim? –

+0

@abdullahcinar Да, вы можете использовать его, считая, что ваша архитектура имеет 8 бит на байт и два дополнения, что почти наверняка. – 2501

+0

Да, я проверил его, и это правда. Поэтому я могу продолжить с этим. Большое спасибо всем вам, у кого есть ответ на этот вопрос. –

1
uint8     Container_ID[10]; 

То беззнаковое 8 битное целое число с возможными значениями от 0 к 255

char     Prefix[10]; 

В вашем случае подписанного 8 битный полукокс с целыми значениями от -127 к +128

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

1

Как выделено в this Ответ на такие смежные аргументы, как нарушение ограничений.

Вы передаете аргумент unsigned char * функции, которая ожидает аргумент char * . Эти два типа несовместимы, и неявное преобразование из одного в другое. Соответствующий компилятор может выдать предупреждение (которое считается диагностическим), а затем перейти к сгенерировать исполняемый файл, но поведение этого исполняемого файла не определено.

Хотя этот ответ для char* против знака char* Я считаю, то же самое должно провести с char*, uint8_t*.

1

char и uint8 имеют что-то общее, и это важно: они являются целыми числами 8 бит. Теперь два вопроса:

  • это/эти/эти 8-битовые целые числа, подписанные или без знака?

И что еще более важно

  • это важно в вашем случае?

I.e. вы хотите отправить в функцию массив из целых чисел, для которого важно, чтобы они считались подписанными? Например, если функция будет делать что-то подобное,

if (charvalue < 0) { ... 

или если вы хотите функции обратить внимание на знаковость байт (если это было бы возможно); если функция будет делать это, и знак будет иметь значение: посылая 255 положительный, но учитывая байт подписи, что бы быть истолковано как -1 ...

Но это не имеет смысла, так как функция принимает uint8 * (на самом деле внутри этой функции разработчики могли использовать char для лечения байт индивидуально, и использовать их знаковость, но в этом случае, имеющей функцию подписи, как это было бы вводить в заблуждение!)

Так E ППЗУ лечения байты без знака, и вы можете безопасно отбросить указатель на функцию, чтобы удалить предупреждение,

CyBle_StoreAppData((uint8 *)Prefix,datastack_ROM,10,0); 

или просто

uint8 Prefix[10]; 

, если это не вызывает другие проблемы/предупреждение с остальной частью кода.

 Смежные вопросы

  • Нет связанных вопросов^_^