^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: 0D3、刪除^M
使用dos2unix工具，將dos下的文件轉換成unix下的文件。
#dos2unix filename注意！
本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系我们删除。