問題タブ [mac-classic]

バックグラウンド：

Mac OS のバージョン 9 までのバージョンでは、テキスト ファイルの標準表現は、ASCII CR (キャリッジ リターン) 文字、値 10 進数 13 を使用して行の終わりを示していました。

Mac OS 10 は、以前のリリースとは異なり、UNIX に似ており、ASCII LF (改行) 文字、値 10 進数 10 を使用して行の終わりをマークします。

問題は、文字定数の値と、OS X より前の Mac OS リリースの C および C++ コンパイラの値は何'\n'ですか'\r'?

取ることができた可能性のある（少なくとも）2つの可能なアプローチがあります。

1. ASCII LF 文字として扱い'\n'、テキスト ストリームへの出力およびテキスト ストリームからの入力で CR との間で変換します (Windows システムでの LF と CR-LF 間の変換と同様)。また
2. '\n'入力または出力で変換を必要としない ASCII CR 文字として扱います。

2 番目のアプローチには、潜在的な問題がいくつかあります。'\n'1 つは、 LFであると想定するコードが失敗する可能性があることです。(このようなコードは本質的に移植性がありません。) もう 1 つは、 には別個の値が必要であり'\r'、ASCII ベースのシステムでは CR が唯一の適切な値であるということです。また、C 標準では許可されていないため'\n' == '\r'(5.2.2 段落 3 の引用を見つけてくれた mafso に感謝します)、他の値を に使用する必要があります'\r'。

Nが 10 未満の場合、Mac OS Nでコンパイルして実行すると、この C プログラムの出力はどうなりますか?

この質問は、C と C++ の両方に当てはまります。答えはどちらも同じだと思います。

答えは C コンパイラによっても異なる可能性がありますが、コンパイラの実装者が互いに一貫性を維持していることを願っています。

明確にするために、Mac OS の古いリリースがテキスト ファイルの行末を表すために使用していた表現を尋ねているわけではありません。私の質問は、定数の値と'\n'C'\r'または C++ ソース コードについてのみです。'\n'テキスト ストリームに出力すると (その値が何であれ)、システムの行末表現 (この場合は ASCII CR) に変換されることは承知しています。その動作は C 標準で必要です。

MacOS 7.x - 9.x (Macintosh Toolbox を使用) で動作する小さなアプリを作成しており、Duktape を含めることにしました。

私は MacOS 9 で実行されている CodeWarrior 6.0 を使用しています。ここ
にある低メモリ構成を使用しています。

PPC 用にコンパイルすると完全に動作しますが、68k 用にコンパイルすると、多くの奇妙な動作が発生してクラッシュします。

たとえばduk_peval_string、次のように呼び出すとします。

var i = 3;<- エラーなし
var i = 3; function a() { return 4; }<- エラーなし
var i = 3; function a() { return 4; } i = a();<-- "ReferenceError: -4e+0"
function a() { return 4; } i = a();<-- 起動時にクラッシュ

セルフテスト ( DUK_USE_SELF_TESTS) を有効にして、何が起こっているのかを把握しようとしました - プロセッサ設定で (68K 設定の代わりに) を有効に8-Byte Doublesして変更すると、Duktape はテストに合格します - それでも問題は解決しません.Struct AlignmentPowerPC

定義する__m68k__(または定義しない) ことは、何にも影響を与えないようです。

私はそれがロングショットであることを知っていますが、IDEとduk_configで見つけることができるほぼすべての設定を変更するのに約4時間費やした後、私はアイデアがありません.