b = *ptr;
  return a * b;
}


由于*ptr的值可能被意想不到地該變，因此a和b可能是不同的。結果，這段代碼可能返不是你所期望的平方值！正確的代碼如下：

long square(volatile int *ptr) 
{
  int a;
  a = *ptr;
  return a * a;
}

位操作（Bit manipulation） 
 
9. 嵌入式系統總是要用戶對變量或寄存器進行位操作。給定一個整型變量a，寫兩段代碼，第一個設置a的bit 3，第二個清除a 的bit 3。在以上兩個操作中，要保持其它位不變。
對這個問題有三種基本的反應
? 不知道如何下手。該被面者從沒做過任何嵌入式系統的工作。
? 用bit fields。Bit fields是被扔到C語言死角的東西，它保證你的代碼在不同編譯器之間是不可移植的，同時也保證了的你的代碼是不可重用的。我最近不幸看到Infineon為其較復雜的通信芯片寫的驅動程序，它用到了bit fields因此完全對我無用，因為我的編譯器用其它的方式來實現bit fields的。從道德講：永遠不要讓一個非嵌入式的家伙粘實際硬件的邊。
? 用 #defines 和 bit masks 操作。這是一個有極高可移植性的方法，是應該被用到的方法。最佳的解決方案如下：


#define BIT3 (0x1 << 3)
static int a;

void set_bit3(void) {
 a |= BIT3;
}
void clear_bit3(void) {
 a &= ~BIT3;
}

一些人喜歡為設置和清除值而定義一個掩碼同時定義一些說明常數，這也是可以接受的。我希望看到幾個要點：說明常數、|=和&=~操作。
訪問固定的內存位置（Accessing fixed memory locations） 
 
10. 嵌入式系統經常具有要求程序員去訪問某特定的內存位置的特點。在某工程中，要求設置一絕對地址為0x67a9的整型變量的值為0xaa66。編譯器是一個純粹的ANSI編譯器。寫代碼去完成這一任務。
這一問題測試你是否知道為了訪問一絕對地址把一個整型數強制轉換（typecast）為一指針是合法的。這一問題的實現方式隨著個人風格不同而不同。典型的類似代碼如下：

int *ptr;
ptr = (int *)0x67a9;
*ptr = 0xaa55;

A more obscure approach is: 
一個較晦澀的方法是：

*(int * const)(0x67a9) = 0xaa55;

即使你的品味更接近第二種方案，但我建議你在面試時使用第一種方案。

中斷（Interrupts） 
 
11. 中斷是嵌入式系統中重要的組成部分，這導致了很多編譯開發商提供一種擴展—讓標準C支持中斷。具代表事實是，產生了一個新的關鍵字__interrupt。下面的代碼就使用了__interrupt關鍵字去定義了一個中斷服務子程序(ISR)，請評論一下這段代碼的。

__interrupt double compute_area  (double  radius) 
{
  double area = PI * radius * radius;
   printf("\nArea = %f", area);
   return area;
}

這個函數有太多的錯誤了，以至讓人不知從何說起了：
? ISR 不能返回一個值。如果你不懂這個，那么你不會被雇用的。
? ISR 不能傳遞參數。如果你沒有看到這一點，你被雇用的機會等同第一項。
? 在許多的處理器/編譯器中，浮點一般都是不可重入的。有些處理器/編譯器需要讓額處的寄存器入棧，有些處理器/編譯器就是不允許在ISR中做浮點運算。此外，ISR應該是短而有效率的，在ISR中做浮點運算是不明智的。
? 與第三點一脈相承，printf()經常有重入和性能上的問題。如果你丟掉了第三和第四點，我不會太為難你的。不用說，如果你能得到后兩點，那么你的被雇用前景越來越光明了。

*****
代碼例子（Code examples）

12 . 下面的代碼輸出是什么，為什么？

void foo(void)
{
  unsigned int a = 6;
  int b = -20;
  (a+b > 6) ? puts("> 6") :  puts("<= 6");
}
這個問題測試你是否懂得C語言中的整數自動轉換原則，我發現有些開發者懂得極少這些東西。不管如何，這無符號整型問題的答案是輸出是 ”>6”。原因是當表達式中存在有符號類型和無符號類型時所有的操作數都自動轉換為無符號類型。 因此-20變成了一個非常大的正整數，所以該表達式計算出的結果大于6。這一點對于應當頻繁用到無符號數據類型的嵌入式系統來說是豐常重要的。如果你答錯了這個問題，你也就到了得不到這份工作的邊緣。
13. 評價下面的代碼片斷：

unsigned int zero = 0;
unsigned int compzero = 0xFFFF; 
/*1's complement of zero */

對于一個int型不是16位的處理器為說，上面的代碼是不正確的。應編寫如下：

unsigned int compzero = ~0;

這一問題真正能揭露出應試者是否懂得處理器字長的重要性。在我的經驗里，好的嵌入式程序員非常準確地明白硬件的細節和它的局限，然而PC機程序往往把硬件作為一個無法避免的煩惱。
    到了這個階段，應試者或者完全垂頭喪氣了或者信心滿滿志在必得。如果顯然應試者不是很好，那么這個測試就在這里結束了。但如果顯然應試者做得不錯，那么我就扔出下面的追加問題，這些問題是比較難的，我想僅僅非常優秀的應試者能做得不錯。提出這些問題，我希望更多看到應試者應付問題的方法，而不是答案。不管如何，你就當是這個娛樂吧…

動態內存分配（Dynamic memory allocation） 
14. 盡管不像非嵌入式計算機那么常見，嵌入式系統還是有從堆（heap）中動態分配內存的過程的。那么嵌入式系統中，動態分配內存可能發生的問題是什么？
這里，我期望應試者能提到內存碎片，碎片收集的問題，變量的持行時間等等。這個主題已經在ESP雜志中被廣泛地討論過了（主要是 P.J. Plauger, 他的解釋遠遠超過我這里能提到的任何解釋），所有回過頭看一下這些雜志吧！讓應試者進入一種虛假的安全感覺后，我拿出這么一個小節目：
下面的代碼片段的輸出是什么，為什么？

char *ptr;
if ((ptr = (char *)malloc(0)) == 
    NULL) 
else
  puts("Got a null pointer");
  puts("Got a valid pointer");
  
    這是一個有趣的問題。最近在我的一個同事不經意把0值傳給了函數malloc，得到了一個合法的指針之后，我才想到這個問題。這就是上面的代碼，該代碼的輸出是“Got a valid pointer”。我用這個來開始討論這樣的一問題，看看被面試者是否想到庫例程這樣做是正確。得到正確的答案固然重要，但解決問題的方法和你做決定的基本原理更重要些。
Typedef 
: 
15 Typedef 在C語言中頻繁用以聲明一個已經存在的數據類型的同義字。也可以用預處理器做類似的事。例如，思考一下下面的例子：

#define dPS  struct s *
typedef  struct s * tPS;
  
以上兩種情況的意圖都是要定義dPS 和 tPS 作為一個指向結構s指針。哪種方法更好呢？（如果有的話）為什么？
    這是一個非常微妙的問題，任何人答對這個問題（正當的原因）是應當被恭喜的。答案是：typedef更好。思考下面的例子：

dPS p1,p2;
tPS p3,p4;
 
第一個擴展為

struct s * p1, p2;
 
.
上面的代碼定義p1為一個指向結構的指，p2為一個實際的結構，這也許不是你想要的。第二個例子正確地定義了p3 和p4 兩個指針。

晦澀的語法
 
16 . C語言同意一些令人震驚的結構,下面的結構是合法的嗎，如果是它做些什么？

int a = 5, b = 7, c;
c = a+++b;

這個問題將做為這個測驗的一個愉快的結尾。不管你相不相信，上面的例子是完全合乎語法的。問題是編譯器如何處理它？水平不高的編譯作者實際上會爭論這個問題，根據最處理原則，編譯器應當能處理盡可能所有合法的用法。因此，上面的代碼被處理成：

c = a++  + b;

因此, 這段代碼持行后a = 6, b = 7, c = 12。
     如果你知道答案，或猜出正確答案，做得好。如果你不知道答案，我也不把這個當作問題。我發現這個問題的最大好處是這是一個關于代碼編寫風格，代碼的可讀性，代碼的可修改性的好的話題。
好了，伙計們，你現在已經做完所有的測試了。這就是我出的C語言測試題，我懷著愉快的心情寫完它，希望你以同樣的心情讀完它。如果是認為這是一個好的測試，那么盡量都用到你的找工作的過程中去吧。天知道也許過個一兩年，我就不做現在的工作，也需要找一個。
Nigel Jones 是一個顧問，現在住在Maryland，當他不在水下時，你能在多個范圍的嵌入項目中找到他。 他很高興能收到讀者的來信，他的email地址是: NAJones@compuserve.com 。
References 
? Jones, Nigel, "In Praise of the #error directive," Embedded Systems Programming, September 1999, p. 114. 
? Jones, Nigel, " Efficient C Code for Eight-bit MCUs ," Embedded Systems Programming, November 1998, p. 66.