アカウント名:
パスワード:
従来方式で書いた場合は保護できないし新方式だと互換性が無いしで中途半端な印象いっそC言語を適当な仮想マシンのコードにコンパイルするほうがマシなんじゃ
いっそC言語を適当な仮想マシンのコードにコンパイルするほうがマシなんじゃ
どういう理屈かサッパリわからん。
valgrind 「呼んだ?」https://ja.wikipedia.org/wiki/Valgrind [wikipedia.org]
標準関数を考えなしで使ってオーバーフロー引き起こすのが主だろうからユーザーコードにリターンする前にライブラリ側が判断してabort返す必要があるて事はC標準関数を低コストに呼べない・呼んだら黙阿弥、互換性もくそもないスタックに作る配列チェックは自前コード内ならメタマクロで十分対応できるしヒープは壊れても平気ではないけどマズ攻撃には使えんし
このC言語もどきの生きる道はどこにあるんだろうね
何よりも既存のCとの互換性を優先している様に見えるが。従来方式で書いた物の場合は自分で保護を既に実装しているはずだし、新方式は置き換え後なんで元のソースとの互換はあんまり考慮する必要はない。
様は、「既存のブツ在りき」なんでないかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
CのVMでも作ればいい (スコア:0)
従来方式で書いた場合は保護できないし
新方式だと互換性が無いしで中途半端な印象
いっそC言語を適当な仮想マシンのコードにコンパイルするほうがマシなんじゃ
Re: (スコア:0)
いっそC言語を適当な仮想マシンのコードにコンパイルするほうがマシなんじゃ
どういう理屈かサッパリわからん。
Re: (スコア:0)
valgrind 「呼んだ?」
https://ja.wikipedia.org/wiki/Valgrind [wikipedia.org]
Re: (スコア:0)
標準関数を考えなしで使ってオーバーフロー引き起こすのが主だろうから
ユーザーコードにリターンする前にライブラリ側が判断してabort返す必要があるて事はC標準関数を低コストに呼べない・呼んだら黙阿弥、互換性もくそもない
スタックに作る配列チェックは自前コード内ならメタマクロで十分対応できるし
ヒープは壊れても平気ではないけどマズ攻撃には使えんし
このC言語もどきの生きる道はどこにあるんだろうね
逆じゃねえの? (スコア:0)
何よりも既存のCとの互換性を優先している様に見えるが。
従来方式で書いた物の場合は自分で保護を既に実装しているはずだし、
新方式は置き換え後なんで元のソースとの互換はあんまり考慮する必要はない。
様は、「既存のブツ在りき」なんでないかな。