スレ立てるまでもない質問はここで 119匹目

952 ：デフォルトの名無しさん：2012/06/30(土) 23:41:55.57

953 ：uy：2012/06/30(土) 23:45:12.81

>>901
俺のコンパイラは、ファイル名を指定するだけで、
どこに置いたファイルでも、瞬時にコンパイルしてくれる！
そんな機能もないゴミカスコンパイラを使ってるのかよ
ゴミゴミゴミゴミゴミゴミゴミゴミゴミｗｗｗｗｗｗｗｗ
さっさと土に還ってリサイクルされろよ

954 ：デフォルトの名無しさん：2012/06/30(土) 23:46:51.96

>>955
それだったら○○で同じ事出来るじゃん

955 ：デフォルトの名無しさん：2012/06/30(土) 23:52:33.54

>>954
なんだこのゴミ

956 ：デフォルトの名無しさん：2012/06/30(土) 23:59:05.50

>>951
データの読み込みやらRPCやら

eval( "[{key:1,value:1}, {key:1,value:1}]" );

command = socket.read();
eval( command );

957 ：デフォルトの名無しさん：2012/07/01(日) 00:00:54.10

あと、Pythonとか汎用言語で作ったプログラムに
スクリプト機能をもたせる場合も非常に楽だな。

958 ：uy：2012/07/01(日) 00:07:22.42

言語にこういう機能あったらいいな～　→　とりあえずevalでコード書いてみる

こういう経験が一度もないならゴミカス

959 ：デフォルトの名無しさん：2012/07/01(日) 00:15:51.43

>>958
ゴミカス筆頭が言うな

960 ：uy：2012/07/01(日) 00:20:32.43

某所たとeval使ってるコードを弾くから、evalはあまり使いたくないな

961 ：デフォルトの名無しさん：2012/07/01(日) 00:20:32.94

>>956
> eval( "[{key:1,value:1}, {key:1,value:1}]" );

これはJSON形式だと思うけど、この形式にはほとんどの言語が対応している。

さらに言うならJSONはJavaScriptの文法であるけれども、evalでやる場合の欠点、
セキュリティ的な問題からJavaScriptでもJSON用のメソッドが用意されたよね。

この2つの事実から、evalは不要で、evalは使うなってことだよ。

したも同様。通信先が安全だという確証がなければ、
そのようなコードは使えない。RPCの利用価値を半分減らしてる。

962 ：デフォルトの名無しさん：2012/07/01(日) 00:25:09.30

>>960
某所たとって何だよ！
日本語を喋れゴミカス野郎！

963 ：uy：2012/07/01(日) 00:40:19.50

すまん、タッチパネルの感度か悪くてな

964 ：uy ◆pdu1UZmweE ：2012/07/01(日) 01:02:37.57

ゴミカスしかいねーじゃねーか

965 ：デフォルトの名無しさん：2012/07/01(日) 01:37:56.54

>>961
JavaScriptで例を書いただけで
Jsonである必要はない
Pythonの言語片でも、Lispの言語片でもGo Langの言語片でもいい。
更に言えば、不審者が書き込むような
ネットのデータで無ければなんら問題ない

966 ：デフォルトの名無しさん：2012/07/01(日) 01:42:35.77

>>961
セキュリティが問題ない環境ならなんら問題ない
あと条件式や、関数を設定として読み込むなんて芸当はJSONじゃできん

967 ：デフォルトの名無しさん：2012/07/01(日) 01:45:58.01

eval()が役に立つのは、すぐに思いつくのは、数式みたいなのを受けるときかな。

セキュリティを意識するなら、インタフェース部分は、C一択だろう。
C++すらなまぬるい。
eval()みたいなもんは、高次部分に、便利に使え。

968 ：デフォルトの名無しさん：2012/07/01(日) 01:47:34.18

安全だと分かってるところで使うなんて大前提で当たり前じゃん
そんな事言われなきゃわかんないのか

969 ：デフォルトの名無しさん：2012/07/01(日) 01:49:56.78

実務で使えないような技術は、
実務ではいらん。

んなもん、実験でのみ使え。
実験用言語としての価値ならあるだろ。

970 ：デフォルトの名無しさん：2012/07/01(日) 01:50:05.14

>>961
>したも同様。通信先が安全だという確証がなければ、
>そのようなコードは使えない。RPCの利用価値を半分減らしてる。

SQLも利用価値半減って事になるな

971 ：デフォルトの名無しさん：2012/07/01(日) 01:52:36.09

>>970
あぁ、他人から受け取ったSQLを自由に実行できるなら
それはSQLインジェクションだからな。

だ・か・ら。値のみを受け取るんだ。
evalの中身を受け取って実行とかアホすぎｗ

972 ：デフォルトの名無しさん：2012/07/01(日) 01:53:13.76

>>969
Googleでも使ってるし、UNIX由来のスタンドアロン系
アプリケーションじゃバリバリ使われてる

お前は一人ちまちま設定の解析コード書いてろ

973 ：デフォルトの名無しさん：2012/07/01(日) 01:53:44.12

>>962
使われてない。

反論終わり。

974 ：デフォルトの名無しさん：2012/07/01(日) 01:54:53.76

>>971
SQLもエンドユーザーに見せないだけで
サーバーに送るときはコードだろうが

evalだってエンドユーザーには見せず
サーバーに送るときだけコードだから変わらん

975 ：デフォルトの名無しさん：2012/07/01(日) 01:55:49.90

eval() の是非論になってきてるが、eval() が欲しければ、
インタプリタをダイナミックリンクしてもいいわけだから、
EXE化のメリットからはちょっと離れてくるね

976 ：デフォルトの名無しさん：2012/07/01(日) 01:56:27.59

emacsとか、vimとか読み込んだコードをevalして
スクリプトとして使ってるなぁ。

977 ：デフォルトの名無しさん：2012/07/01(日) 01:56:31.01

>>972
> お前は一人ちまちま設定の解析コード書いてろ

用意されているevalメソッドを使うように、
用意されている設定を解析する、parseメソッドを使うだけです。

いちいち解析コードなんて書きません。
それともevalの実装コードでも書くのですか？

978 ：デフォルトの名無しさん：2012/07/01(日) 01:59:38.99

RPCの話が出てたが、ある意味静的言語でやったRPCもevalみたいなもんだからな。
evalとリスクは変わらんよな。

979 ：デフォルトの名無しさん：2012/07/01(日) 02:01:53.11

用途ごとにParseを用意するメンドさ
新しいParse更新をするメンドさ

980 ：デフォルトの名無しさん：2012/07/01(日) 02:02:28.19

使いやすいeval の実装の選定に時間を割くといえば、似たようなもんだなｗ

結局、複雑で便利なモジュールは、なにしても穴がゼロにならんから、
低権限で動作するスレッドに任せるかなんかせんとしょうがないね

981 ：デフォルトの名無しさん：2012/07/01(日) 02:03:30.77

じゃあ、お前のevalで
JSONとYAMLを両方パースできるの？

あ、evalですでに用意されている設定を解析するメソッドを使うのか、くくく

982 ：デフォルトの名無しさん：2012/07/01(日) 02:13:16.24

最初から存在するevalをつかって設定を管理したいというのに
なぜ別のデータ形式の話が出てくるのか？

983 ：デフォルトの名無しさん：2012/07/01(日) 02:20:59.12

bashや、zshの設定は全部bashやzshのスクリプト形式で書いてある。
vimは、vim script, emacsは、emacs lisp, firefox、chromeのアドオンは一部javascript
世の中使ってるところは使ってるんだから、使い奴は自己責任で使えばいい。
ネット越しでやりとりするんじゃなけりゃまず困らないんだから。

984 ：デフォルトの名無しさん：2012/07/01(日) 03:13:32.05

> 最初から存在するevalをつかって設定を管理したいというのに
それは別の方法で簡単にできることだから、する必要ないし
逆にセキュリティホールをまねくからやらないほうがいいという話。

無理に使う必要はないんだよ。
適切なものを使いましょう。

985 ：デフォルトの名無しさん：2012/07/01(日) 05:32:00.82

自分らで書いた設定を読み込むのにセキュリティホール？

986 ：デフォルトの名無しさん：2012/07/01(日) 05:48:02.60

設定ファイルは、アプリ開発社内人が
作成することもあるんだよ。

987 ：デフォルトの名無しさん：2012/07/01(日) 06:32:20.56

>>964
ゴミカスが言うな

988 ：uy：2012/07/01(日) 07:13:24.47

>>967
お前よくバカって言われるだろ

>>985なんでそれすらわからないの？

>>987
死ねゴミ

989 ：uy：2012/07/01(日) 07:27:50.60

用意されてるんだから需要はある
eval使うと簡単に実装出来るモノもあるし
速度とかセキュリティとかは必要な時に考慮すればいい

>>983
思いっ切り話題から外れてる
そいつらはインタプリタの実装
インタプリタ言語で書かれたプログラムの中でevalを使うことの是非の話だ

990 ：デフォルトの名無しさん：2012/07/01(日) 07:34:16.77

>>989
ゴミカスはゴミ箱に籠もってろ

991 ：デフォルトの名無しさん：2012/07/01(日) 08:33:29.20

どなたか次スレお願いします

992 ：デフォルトの名無しさん：2012/07/01(日) 08:49:41.52

次スレ
http://toro.2ch.net/test/read.cgi/tech/1341099441/

993 ：uy ◆pdu1UZmweE ：2012/07/01(日) 09:11:33.69

ねむいは

994 ：デフォルトの名無しさん：2012/07/01(日) 10:10:54.08

>>984
逆だ。evalで済むものをわざわざ別で用意するのがおかしい。

>>986
で、なんの問題があるんだ？開発関係者が信用できないなら
設定ファイル以前にソースコードすら信用出来んだろ。

995 ：デフォルトの名無しさん：2012/07/01(日) 10:21:55.41

>>984
スタンドアロンでeval実行した場合のセキュリティホールって具体的に何だよ
そもそもセキュリティ問題に関してとって付けて言ってるだけで理解してないだろ
スタンドアロンでeval実行が問題になるんならインタープリターやコンパイラー
入れてる時点でアウトだし、単にXMLで書いた設定ファイルだってオーバーランや
オーバーフローのバグでセキュリティホールになる

996 ：デフォルトの名無しさん：2012/07/01(日) 10:26:05.14

DLL利用したものだって、DLL上書きされりゃアウトだしな。

997 ：デフォルトの名無しさん：2012/07/01(日) 10:29:59.83

設定で危険といえばApacheやSend Mailもそうだな。
管理者以外編集できなくなってるから普通きにしないけど。

998 ：デフォルトの名無しさん：2012/07/01(日) 10:46:39.92

そもそも1024以下のポート使ってる時点でroot必須だしなあ

999 ：デフォルトの名無しさん：2012/07/01(日) 11:00:34.57

不特定多数でやりとりするのか個々で独立して管理するのかで
脆弱性を区別できない人のソフトなんて使いたくねぇな

1000 ：デフォルトの名無しさん：2012/07/01(日) 11:06:18.16

1000ならuyとQZaw55cn4c死亡

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。