我有一個API，可實現對EEPROM的寫操作。 這是它的聲明：

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

當我調用此函數并將數組參數發送到已聲明為uint8類型的srcBuff時，它工作得很好。

問題是，我需要向它發送char數組指針。 我以為char已經是uint8，但是如果我向該函數而不是uint8發送char數組指針，則會收到編譯器警告。 為什么不能使用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不一樣嗎？

錯誤消息中的重要內容是有關"不同符號"的部分。 這意味著您的char類型是signed，而uint8是(假設在這里)unsigned。 它可能不會成為一個大問題，所以您應該只應該可以投射指針：CyBle_StoreAppData((uint8 *) Prefix, ...)

請注意：這似乎違反了約束，請注意：stackoverflow.com/questions/30535814/

@GiorgiMoniava我已經尋找了類似的問題，但我想我找不到。 我該如何提一個類似的問題？ 還是我需要這樣做？

char和uint8都有共同點，這很重要：它們都是8位整數。現在兩個問題

/這8位整數是帶符號的還是無符號的？

更重要的是

您的情況重要嗎？

即您是否要向函數發送一個由整數組成的數組，將其視為帶符號的整數很重要？例如，如果函數將執行類似的操作，

if (charvalue < 0) { ...

或者如果您想讓函數注意字節的有符號性(如果可能)；或者如果函數能夠做到這一點，那么符號就很重要：發送255是肯定的，但考慮到帶符號的字節，則將其解釋為-1 ...

但這是沒有意義的，因為該函數需要uint8 *(實際上，在開發人員內部，開發人員可能已經使用char分別對待字節并使用其簽名)，但是在這種情況下，具有這樣的函數簽名將非常有用誤導！)

因此，E2PROM正在處理無符號字節，您可以放心地將賦予函數的指針強制轉換為刪除警告，

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

或簡單地

uint8 ?Prefix[10];

如果那不會導致其他問題/其他代碼警告。

uint8 ? ? ? ? ? ? ? ? ? Container_ID[10];

多數民眾贊成在一個無符號的8位整數，可能的值從0到255

char ? ? ? ? ? ? ? ? ? ?Prefix[10];

您的情況是帶符號的8位字符，其整數值從-127到+128

因為它們不是相同的符號類型，所以您會收到應有的轉換警告。

兩種類型均為8位長。區別在于簽名。

uint8類型是無符號的。

char類型應根據您的情況進行簽名。實際上，它依賴于編譯器，但是大多數編譯器默認將char類型視為帶符號，并可以根據需要選擇將char類型強制為無符號。請參閱C99標準文檔參考§6.2.5p15：

The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char.

CHAR_MIN, defined in limits.h, will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the two options.

我不認為這是依賴編譯器的。我找到了此鏈接。但是，如果我聲明Container_ID為無符號，則無法使用將其用于其他作業的字符串函數。所以我應該像在@Joachims答案上一樣投射它嗎？

看到我的編輯，我添加了對C標準的引用。但是可以，您可以按照建議進行投放。

謝謝:)這是解釋性的。我確認我的編譯器已將其視為已簽名。因此，我使用了強制轉換操作，并且效果很好。謝謝你們。

@abdullahcinar您的鏈接僅指向特定的編譯器和平臺。 ARM的正常目標是將默認純字符設置為unsigned。由于世界上ARM CPU的數量比PC多，所以說char通常是無符號的可能更正確！

uint8_t很可能被定義為無符號字符。

char是它自己的類型，其行為與帶符號字符或無符號字符完全一樣(請注意，這是三種不同的類型)。

在這種情況下，它的行為就像帶符號的char一樣，您會收到轉換警告。

我不認為這是依賴編譯器的。我找到了此鏈接。但是，如果我聲明Container_ID為無符號，則無法使用將其用于其他作業的字符串函數。所以我應該像在@Joachims答案上一樣投射它嗎？

@abdullahcinar是的，您可以強制轉換它，假設您的體系結構每字節有8位，并且二進制補碼，幾乎可以肯定。

是的，我檢查了它的真實性。所以我可以繼續。非常感謝所有對此問題有解答的人。

我非常確定，在這種情況下，即使在char是未簽名的平臺上，gcc也會發出"有區別的簽名"轉換警告。

@plugwash不，我可以為您引用標準。 char從字面上看與簽名char或未簽名char相同，只是它是自己的類型。 (請不要基于對我的主觀感受而拒絕投票。昨天我只是在嘗試幫助您并且犯了一個錯誤，您可以查看評論，對此我表示歉意。)

@plugwash我剛剛用-Wall -Wextra -Wconversion用gcc 5.1.0進行了檢查，當char和int8_t的符號匹配時，它不給出警告，而當它們與我的答案不匹配時，它給出錯誤。這是一個實際的例子。理論方面在C11 6.2.5。，第15頁中作了解釋。我認為您所關注的內容無效。

總結

以上是生活随笔為你收集整理的c语言char和int8,关于数组：C中uint8和char之间的转换的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。