Для реализаций Apple (Cocoa / CocoaTouch) всегда ли тип uint8_t совпадает с типом без знака?

Question

Проходя через пример приложения кода для iPhone, я обнаружил пару методов отправки / получения, которые фактически имели одинаковые определения сигнатур, за исключением типов значений, связанных с одной из переменных.

Из заголовка:

- (void)receivedData: (unsigned char *)data length:(NSUInteger)len;
- (void)sendData:     (uint8_t*)       data length:(NSUInteger) len;

Эти методы используются в качестве оболочек для процесса отправки / получения, который фактически передает указатель на массив byte данных, записываемых в потоки данных и из них. Мне показалось, что эти сигнатуры методов немного любопытны, и, поскольку я новичок в разработке Cocoa / Cocoa Touch, я решил проверить определение типа uint8_t. Я обнаружил, что uint8_t определяется как unsigned char в пределах stdint.h и, следовательно, переменные data для этих методов абсолютно одинаковы. По крайней мере, так обстоит дело с stdint.h, который связан в XCode 4.2.

Однако, проведя небольшое исследование относительно типа uint8_t, я нашел этот вопрос относительно использования uint8_t против unsigned char. Похоже, консенсус заключается в том, что довольно часто эти два типа значений абсолютно одинаковы, но в некоторых реализациях стандартных библиотек C они могут отличаться. Поэтому не стоит полагать, что они будут представлять собой данные одного типа при создании переносимого кода.

С учетом вышесказанного, можно ли предположить из среды программирования Apple / Objective-C, что uint8_t будет таким же, как unsigned char, или я должен следовать тем же советам, что и в приведенном выше вопросе?

Может показаться, что это довольно требовательный вопрос, но, поскольку я могу интегрировать библиотеки, в которых этот тип кодирования кажется немного распространенным, в личную кодовую базу, которую можно использовать в нескольких средах Apple (для довольно через несколько лет) я хотел бы получить дополнительные комментарии.

Answer 1

Можно с уверенностью предположить, uint8_t является typedef для unsigned char в Mac OS X.

Для систем, которые следуют POSIX (как Mac OS X), POSIX требует, чтобы тип char был равен 8-bit.

(2.12.2 Тип char) "Тип char определен как один байт; см. Определения XBD (Байт и Символ)."

и

(3,84 байт) "Индивидуально адресуемая единица хранения данных, представляющая собой точно октет, используемая для хранения символа или части символа; см. также Символ. Байт состоит изнепрерывная последовательность из 8 битов. "

Answer 2

Игнорируя вопросы переносимости (как вы неявно просили нас сделать), представляется крайне маловероятным, что char будет когда-либо отличаться от восьмибитного значения в Mac OS X и его производных, таких как iOS. Я думаю, вы можете с уверенностью предположить, что unsigned char и uint8_t всегда будут одинаковыми.

Тем не менее, я думаю, что как форма документации для программистов, которая придет за вами, когда вы имеете дело со значением, предназначенным для хранения байта двоичных данных, а не символа, кажется разумнее использовать «байт» или «uint8_t» или некоторый аналогичный метод указания будущим читателям, что целью функции является обработка значения как байта, а не как символа как такового.

Answer 3

Хотя стандарт C99 допускает, что uint8_t и unsigned char различаются, на практике все основные операционные системы - особенно UNIX-подобные системы, такие как семейство Apple OS - будут иметь одинаковые значения по простой причине.что существует слишком много кода (до и после C99), который предполагает, что unsigned char имеет ширину ровно 8 бит.

При этом, uint8_t естественно безопаснее с теоретической точки зрения, поэтомунет особых причин не использовать его.Вам не нужно бояться библиотек, использующих unsigned char.

Answer 4

Я бы сказал, что вы можете использовать их взаимозаменяемо в среде Apple. Насколько я понимаю, странные реализации, которые трактуют unsigned char как что-то отличное от 8 байтов, - это совсем немного, и, по моему скромному мнению, идиот;)

Apple, основывающая свои ОС на UNIX-подобных базах, почти наверняка никогда не изменит реализацию unsigned char.