^M導致的編譯出錯


有時候我們會在Windows下編寫代碼,然后再放到Linux下進行編譯。此時就會涉及到兩個系統對換行符的解釋了。不同的解釋,就會造成一些奇怪的錯誤。


1、問題描述

在SourceInsight上查看main()函數,這么一看,沒啥毛病。
這里寫圖片描述

但是當我將該文件放到Linux上使用gcc進行編譯,編譯出錯,提示第322行出錯,但是322行是return 0;沒啥毛病啊。
這里寫圖片描述

我把321行和322行屏蔽掉,再次編譯,同樣會出錯,出錯跟上次不一樣。
這里寫圖片描述

這里寫圖片描述

在Linux系統中打開這個文件,發現有個奇怪的地方,在a test中間有個^M的字符。
這里寫圖片描述

這個字符在Linux會被解釋成換行,於是上面就等價於:
這里寫圖片描述

這就能解釋為什么第二次編譯會出現那種出錯了。在Windows下我們看不出^M的存在,看起來像是個空格,但是在Linux下^M會影響到整個代碼的格式,於是有可能會出現錯誤。

要模擬上述的情況其實很簡單。在SourceInsight可以插入一個ASCII字符。
Edit -> Special Edit -> Insert ASCII..
輸入0xd的字符就可以出現^M了。


2、Windows/Linux對換行的解釋

Windows:  0D0A 
Unix\Linux: 0A
MAC: 0D

3、刪除^M

使用dos2unix工具,將dos下的文件轉換成unix下的文件。

#dos2unix filename

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com