まず、あなたの C コードは C コードではありません。近いですが、そのままではまったくコンパイルされません。次に、コードをクリーンアップしてコンパイル可能な状態にした後:
#include <stdio.h>
#include <stdlib.h>
char fileContents[] = "hi\n whats up\n";
int main(void)
{
char *output;
int i;
int j;
char *bPtr;
output = malloc(1024);
bPtr = fileContents;
for (i = j = 0 ; bPtr[i] != '\0' ; i++)
{
if ('\n' == bPtr[i])
output[j++] = '\r';
output[j++] = bPtr[i];
}
output[j] = '\0';
fputs(output,stdout);
return EXIT_SUCCESS;
}
そして、「gcc -g ac」でコンパイルし、gdb を使用します。
GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".
(gdb) break 17
Breakpoint 1 at 0x80483fa: file a.c, line 17.
(gdb) run
Starting program: /tmp/a.out
Breakpoint 1, main () at a.c:17
17 for (i = j = 0 ; bPtr[i] != '\0' ; i++)
(gdb) n
19 if ('\n' == bPtr[i])
(gdb) n
21 output[j++] = bPtr[i];
(gdb) n
17 for (i = j = 0 ; bPtr[i] != '\0' ; i++)
(gdb) n
19 if ('\n' == bPtr[i])
(gdb) n
21 output[j++] = bPtr[i];
(gdb) n
17 for (i = j = 0 ; bPtr[i] != '\0' ; i++)
(gdb) n
19 if ('\n' == bPtr[i])
(gdb) n
20 output[j++] = '\r';
(gdb) n
21 output[j++] = bPtr[i];
ループの最初の 2 回では、条件が false であるため、条件をスキップします。3 回目で条件が満たされ、「\r」が出力に含まれます。
しかし、あなたの他のコメントのいくつかを読むと、行末に混乱しているようです。Unix では (Linux は Unix の一種であるため、これは Linux にも当てはまります)、行は LF (ASCII コード 10) という 1 文字で終わります。Windows (および Windows の前身である MS-DOS、および MS-DOS の前身である CP/M) は、文字列 CR LF (ASCII コード 13、ASCII コード 10) を使用して、行の終わりをマークします。
2 つの異なる基準はなぜですか? ASCII 標準の文言、それが作成された時期と理由のためです。それが作成されたとき、出力は主にテレタイプでした---タイプライターを考えてみてください。CR は印刷キャリッジ (または印刷ヘッド) を行の先頭に戻すことと定義され、LF は次の行に進むことと定義されました。プリント キャリッジを次の先頭に移動するアクション。行が指定されていませんでした。CP/M (およびその子孫) は、標準文書のかなり文字通りの翻訳のために、両方を使用して行末をマークすることを標準化しました。Unix の作成者は、改行である LF が出力のために次の行に進むことを意味する、より自由な解釈を決定しました。キャリッジを先頭に戻し、次の行に進みます)。
ここで、テレタイプ デバイスが Unix システムに接続されており、CR と LF の両方が必要な場合、Unix デバイス ドライバーは、LF を検出したときに、必要な CR を追加する必要があります。つまり、システムがプログラムに代わって詳細を処理し、必要なのは行末の LF だけです。
混乱をさらに混乱させるのは、C 標準の影響です。ファイルを開くと、
FILE *fp = fopen("sometextfile.txt","r");
「テキスト」モードで開きます。Unix ではこれは何もしませんが、Windows では C ライブラリが入力の "\r" を破棄するので、プログラムは "\n" を探すことだけに気を配る必要があります (書き込み用に開かれたファイルの場合は、CR を追加します) LF が見られる場合)。しかし、これは Windows での話です (これを行うシステムは他にもあるかもしれませんが、私はよく知りません)。
本当にファイルをそのまま表示したい場合は、バイナリ モードで開く必要があります。
FILE *fp = fopen("sometextfile.txt","rb");
これで、ファイルに CR があれば、プログラムはそれを認識します。通常、行末を気にする必要はありません。あるシステムから別の行末規則を使用する別のシステムにテキスト ファイルを移動する場合にのみ、それが問題になります。が問題を処理してくれる場合があります (FTP など)。でもチェックしておいて損はありません。
Unix は「テキスト」モードと「バイナリ」モードを区別しないと言ったのを覚えていますか? そうではありません。そのため、Windows の世界のテキスト ファイルは Unix プログラムで処理され、Unix プログラムには CR が表示されます。何が起こるかは、問題のプログラム次第です。grep のようなプログラムは気にしないようですが、私が使用するエディターは存在する CR を表示します。
さて、私の質問は---何をしようとしているのですか?