由編譯器指定陣列長度帶來的乙個問題

【目的】

在main.c檔案中使用在header.c檔案中定義在header.h中宣告的由編譯器指定長度的陣列

【**】

1 #include "

arraytest.h"2
345 unsigned char array = ;67
8910void print_arraysize0(void)11

1 #include 2

3#ifndef __arraytest_h__ 
4#define __arraytest_h__ 56
78extern unsigned char
array;910
11void print_arraysize0(void
); 12
1314
#endif

1 #include "

arraytest.h"2
3456
void print_arraysize(void)7
1213
14void print_array(unsigned char *array)
1522}23
2425
int main(void)26

c-free5.0， keil5.20

【編譯執行結果】

> 開啟函式 print_arraysize 內的列印功能，則執行結果為

【分析及結論】

> 由於定義的陣列大小是由編譯器分配的，在檔案中使用  sizeof(array)  是ok的，在檔案中使用 sizeof(array) 就報錯，因為檔案中使用 sizeof(array) 的陣列是檔案宣告的 extern unsigned char array，這就讓編譯其誤認為此陣列未指定大小，導致使用 sizeof(array)  報錯

> 不論是在原始檔還是標頭檔案中，陣列大小由編譯器分配，陣列的內容都能正確訪問，就是如 sizeof 等部分函式功能無法使用

乙個陣列長度問題引發的思考

var arr arr 0 0 arr 1 1 arr.foo c console.log arr.length 為什麼.length不會把foo算進陣列長度？進一步思考為什麼關聯陣列沒有陣列長度？var arr arr 5 1 arr.foo c console.log arr.length 結合...

由乙個錯誤說const的用法，兼談編譯器

今日，對乙個函式進行改寫，發現編譯錯誤。原程式和錯誤如下 std string getresult const std string strinput,const std map mapresult 我本人仔細想了想，錯誤原因是這樣的 1 map本身的操作，從語法上是這樣的 如果存在相應key值，則...

乙個編譯器的小陷阱

有時候在乙個平台執行正確的程式，在另乙個平台就會出問題。在平台移植中，最常見的問題可能就是位元組序和對齊這類問題了。本文記錄的是我以前碰到過的乙個小陷阱。看看這段 的輸出應該是什麼？include stdio.h char do something int p void test1 void int...