有時候我們會在Windows下編寫代碼,然后再放到Linux下進行編譯。此時就會涉及到兩個系統對換行符的解釋了。不同的解釋,就會造成一些奇怪的錯誤。
在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了。
Windows: 0D0A
Unix\Linux: 0A
MAC: 0D
使用dos2unix工具,將dos下的文件轉換成unix下的文件。
#dos2unix filename
本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。