アカウント名:
パスワード:
脱線気味ですが。某B社のPascal言語環境で、コンパイルしたアプリが処理が正常に行われなかったり、オーバーフローしたりしたことが・・・。diffでソースの差分をみても特に異常があるわけでもない。そして、いろいろ試行錯誤しているうちに、動作とはまったく関係ない「はず」のコメント行を削ってみたら正常に動作したことが。あの会社の開発環境は信じられなくなりました。
他の方も仰っている通り、某B社のT**** Pascalでは、中括弧でくくるタイプのコメント中に日本語は御法度でした。Pascalのコメントには
{ comment }
と
(* comment *)
の2つの形式がありますけど、前者のコメント中で第2バイトに$7D('}')が来る文字(シフトJISでは全角カタカナの'マ'とか)を使用すると、コンパイラはそこでコメントが終わったものと解釈してしまいます。そこから後のコメントが偶然コンパイルが通ってしまう内容だったりすると、動作に影響を与えることもありそうです。
B社のコンパイラはIDE側の設定によってコンパイラオプションが変わることを防ぐために、まさに各ソースコードのコメント部にコンパイラオプションを埋め込んでコンパイラの挙動を制御することが可能です。
このあたりは基本なのですが、おそらく元コメントの方はその存在を知らなかっただけでは。
元コメントの人です。
いや、そういうコンパイラオプションではなく、ふつーに処理の説明を書いたコメントですよ。元々コメントが入ったコードをいじって、動かなくなった状態で、コンパイラオプションとかでは「全くない」元からあったコメント行を削除したら動作したという話です。
あれはどう考えてもB社のコンパイラの不具合だと思う。
言語環境が想定外だったとか。昔だとShiftJISなコメントのあるソースは正常にコンパイルできなかったりするのはざらだったし。# そういや最近batファイルでやられたな
コメントを含む全てを手で丸写しすると治った事があります。(1500行くらいだったので、構文などを確認しながらもう一度書いてみた)
書いてある内容は全く同じハズなのに動き出した。・・・改行の数が変わったからだったのか、いまでも不明。
# ホントはハードエンジニアなのでAC
#!/usr/local/bin/perl[CR][LF]
になってて動かないというのはありがちです。
CRLFに変換されてしまう可能性がある場合、 #! /usr/bin/perl -- と書いておくと良いですよ。
多バイト文字に完全対応できてない処理系だと、コメント内の文字の2バイト目の特定コードで誤作動とかはありえる話。有名どころでは C++ の行コメント末尾の文字の最終バイトが \ の場合、連結された次の行までいっしょにコメント扱いされてしまうとか。その回避策として、今も行コメント末尾に半角スペースをつけてるオレってイケてない?
似た話で MS-DOS の頃、ファイル名の先頭バイトが e5h だと削除済エントリになっちゃうって理由で、1バイト目が e5 の漢字は別のコードに置き換えられていたような記憶があるけど、あれは今はどうなってんだろう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
コメント行を削除すると解決!? (スコア:1, 興味深い)
脱線気味ですが。
某B社のPascal言語環境で、コンパイルしたアプリが処理が正常に行われなかったり、オーバーフローしたりしたことが・・・。
diffでソースの差分をみても特に異常があるわけでもない。
そして、いろいろ試行錯誤しているうちに、動作とはまったく関係ない「はず」のコメント行を削ってみたら正常に動作したことが。
あの会社の開発環境は信じられなくなりました。
Re:コメント行を削除すると解決!? (スコア:2, 参考になる)
他の方も仰っている通り、某B社のT**** Pascalでは、中括弧でくくるタイプのコメント中に日本語は御法度でした。
Pascalのコメントには
と
の2つの形式がありますけど、前者のコメント中で第2バイトに$7D('}')が来る文字(シフトJISでは全角カタカナの'マ'とか)を使用すると、コンパイラはそこでコメントが終わったものと解釈してしまいます。
そこから後のコメントが偶然コンパイルが通ってしまう内容だったりすると、動作に影響を与えることもありそうです。
Re: (スコア:0)
// どの文字が危険だったか覚えて無いけど
foo();
のタイプのコメントで、コメントの末尾が2バイト目が\の文字の場合に改行がエスケープされちゃって
// どの文字が危険だったか覚えて無いけ?■foo();
みたいに行末が潰れつつ1行扱いにされてしまうというのが。
その文字コードにする必要があったけど、コンパイラの方はどうしようもなさそうで、 その文字コードを正しく扱えるgrepか何かを探してきて、事前にすべての行末にスペースを追加してからコンパイルするようにmakeを書き換えたんだったか。
もちろん、後日、"\を含む文字が入ってる文字列"がコード中に出てきて破綻しましたが。
Re:コメント行を削除すると解決!? (スコア:1)
昔々コンパイルオプションをソース中のコメントで指定するコンパイラがありましたが.
(某M社の大型機用だったかな?)
Re: (スコア:0)
B社のコンパイラはIDE側の設定によってコンパイラオプションが変わることを防ぐために、
まさに各ソースコードのコメント部にコンパイラオプションを埋め込んでコンパイラの挙動を制御することが可能です。
このあたりは基本なのですが、おそらく元コメントの方はその存在を知らなかっただけでは。
Re: (スコア:0)
元コメントの人です。
いや、そういうコンパイラオプションではなく、ふつーに処理の説明を書いたコメントですよ。
元々コメントが入ったコードをいじって、動かなくなった状態で、コンパイラオプションとかでは「全くない」元からあったコメント行を削除したら動作したという話です。
あれはどう考えてもB社のコンパイラの不具合だと思う。
Re: (スコア:0)
言語環境が想定外だったとか。
昔だとShiftJISなコメントのあるソースは正常にコンパイルできなかったりするのはざらだったし。
# そういや最近batファイルでやられたな
Re: (スコア:0)
> (某M社の大型機用だったかな?)
TurboPascalなどもそうですけど、あれは統合開発環境だからというのもあるかな
Re:コメント行を削除すると解決!? (スコア:1)
コメントを含む全てを手で丸写しすると治った事があります。
(1500行くらいだったので、構文などを確認しながらもう一度書いてみた)
書いてある内容は全く同じハズなのに動き出した。
・・・改行の数が変わったからだったのか、いまでも不明。
# ホントはハードエンジニアなのでAC
Re:コメント行を削除すると解決!? (スコア:1)
Re:コメント行を削除すると解決!? (スコア:1)
Re:コメント行を削除すると解決!? (スコア:1)
#!/usr/local/bin/perl[CR][LF]
になってて動かないというのはありがちです。
Re:コメント行を削除すると解決!? (スコア:2)
CRLFに変換されてしまう可能性がある場合、 #! /usr/bin/perl -- と書いておくと良いですよ。
HIRATA Yasuyuki
Re: (スコア:0)
近くのコメント行を分割したり結合したりすると戻るというのを経験したことがあります。
あれは未だに納得がいきません。
Re: (スコア:0)
多バイト文字に完全対応できてない処理系だと、コメント内の文字の2バイト目の特定コードで誤作動とかはありえる話。
有名どころでは C++ の行コメント末尾の文字の最終バイトが \ の場合、連結された次の行までいっしょにコメント扱いされてしまうとか。
その回避策として、今も行コメント末尾に半角スペースをつけてるオレってイケてない?
似た話で MS-DOS の頃、ファイル名の先頭バイトが e5h だと削除済エントリになっちゃうって理由で、1バイト目が e5 の漢字は別のコードに置き換えられていたような記憶があるけど、あれは今はどうなってんだろう。
Re: (スコア:0)
0xe5 -> 0x05の置き換えですね。VFATでも、8+3形式のファイル名については今でもこの置き換えが行われていますよ(そうしないと互換が取れなくなっちゃうので)。
exFATでは8+3形式ファイル名がなくなるそうなので、この変換もなくなっているはずです。
Re: (スコア:0)
他の人の作ったプログラムの話だったから、そのままコメント残したって対処だったような気が。