Rust part30

**デフォルトの名無しさん** · 2025/06/16(月) 05:39:40.78

ヌルポ😳😳

Google Cloud、世界中のリージョンが影響を受けた大規模障害、原因は管理システムがヌルポインタ参照でクラッシュしたこと
2025年6月16日
https://www.publickey1.jp/blog/25/google_cloud_3.html

**デフォルトの名無しさん** · 2025/06/16(月) 06:07:30.55

記事あんま理解できてないけどヌルポインタってそんなにまずいもんなの？
コンパイラーが検出してくれるし、スコープから外れた変数はドロップされるからそもそも参照されないかと思ってた

**デフォルトの名無しさん** · 2025/06/16(月) 06:43:29.69

ヌルポインタ参照って
プログラムをCとかunsafeとか使わずにRustで全て作ってるとしたら起き得ないことであってる？

**デフォルトの名無しさん** · 2025/06/16(月) 08:20:04.56

>>808-809
ヌルポインタの問題は型の非互換性、本質的には機能の非互換性の問題。

古いJavaで顕著だけど、ヌルポインタは何の機能もサポートしないのにコンパイル時はほとんどすべての型に化けることができるから、コンパイル時に問題を発見できずに実行時に問題になることがある。
本来なら互換性を保つためにヌルオブジェクトとかを使うべきだけど、言語で禁止しているわけではないので、低能力コーダーとか無能ライブラリアンとかはヌルポインタを返す関数とかを作って問題になる。

safe rust は基本的にヌルポインタを使えないので、このようなトラブルになることは少ないかと。

**デフォルトの名無しさん** · 2025/06/16(月) 11:48:14.62

問題の本質はヌルポじゃないだろ
publickeyの人はそれがわかってない

てかGoogleの品質管理体制も杜撰すぎるな

**デフォルトの名無しさん** · 2025/06/16(月) 12:21:10.35

ガッ！

**デフォルトの名無しさん** · 2025/06/16(月) 12:30:45.07

空白のフィールド含んだだけでクラッシュとかよく分かんないよ
俺がテストせずにこのプログラムをリリースさせた責任者だったら会社に残れないな。明らかにテスト捏造してるから
——
新しいポリシーデータには意図せず空白のフィールドが含まれており、これをサービスコントロールが読み込んで実行したところ、ヌルポインタ参照となりクラッシュが発生します
——

**デフォルトの名無しさん** · 2025/06/16(月) 13:38:36.81

要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ
たまたま結果としてヌルポでクラッシュしただけで、仮にヌルポの可能性に気づけていたとしてもそれ自体がバグの原因でない以上、
問題のパターンが別の形で障害を起こしていた可能性を否定できないな

**デフォルトの名無しさん** · 2025/06/16(月) 14:56:07.05

もしRustで実装していれば、パニックですんでいたのにな

**デフォルトの名無しさん** · 2025/06/16(月) 15:28:10.23

今回の事態を招いた最も重大な要因は「リリース手続きの欠陥」であって、ヌルポ参照という"クラッシュに至る個別の事象"に着目した対策に終始するのは悪手（ヌルポ参照以外の要因で本件のような事象が再発しても良いのか、という問いにyesと答えることに他ならない）

**デフォルトの名無しさん** · 2025/06/16(月) 15:38:50.32

>>814
>要は不具合を引き起こす特定のパターンがあり、テストで発見されなかったってことだろ

特定のパターンというか「新機能のために新しく適用する全世界共通のポリシーデータ」と「新機能」の組み合わせでクラッシュするんだから本番環境に適用するポリシーデータでは一切テストしてなかったってことでしょ

feature flagがなければステージングでのテストも行わず本番と同時適用ってのも意味がわからない

**デフォルトの名無しさん** · 2025/06/16(月) 15:40:30.06

>>815
パニックでも結果は同じ

**デフォルトの名無しさん** · 2025/06/16(月) 16:50:55.12

>>815
Rustで実装していればOption型になる
unwrapしない限りpanicは起きない

**デフォルトの名無しさん** · 2025/06/16(月) 17:11:52.79

JavaはTとOption<T>を区別しないからStringでもnull検査パスしてるか分からんのよね
誰かが検査してると思ってたら誰も検査してなかったり逆に至る所で何重にも検査されてたり

**デフォルトの名無しさん** · 2025/06/16(月) 17:56:55.33

>>819
今回のやつはRustで実装しててもunwrapしてたケースだろう

>>820
Javaの場合は@Nullableみたいなアノテーション使ってビルド時にチェッカーを走らせる

**デフォルトの名無しさん** · 2025/06/16(月) 18:02:11.42

>>821
Optionをunwrapしていいのは常にSome自明時と
異常時にpanicで落ちていい時のみ

**デフォルトの名無しさん** · 2025/06/16(月) 18:48:18.73

>>822
後者に該当

ポリシーデータから必須項目が欠落しているような状態はヌルポを発生させたプログラマーから見ればプログラムを即停止すべき異常事態という認識

**デフォルトの名無しさん** · 2025/06/16(月) 19:02:14.08

Rustはわりとunwrapというかコンテキスト外し一般を使う人が多い印象があるね
そのあたりはやはりベターC++という感じがする

**デフォルトの名無しさん** · 2025/06/16(月) 19:03:13.08

>>823
異常時に停止してよい時のみpanicが使われて暴走やセキュリティの穴を防止するんだよ

**デフォルトの名無しさん** · 2025/06/16(月) 19:04:58.04

>>824
落ちてはいけないプログラムでそんなことする人はいないよ

**デフォルトの名無しさん** · 2025/06/16(月) 19:45:53.03

>>823
panicにするかどうかを決めるのはサーバーを実装する側じゃなくてサーバーを使うユーザー側だろ。
Linusじゃないけど、サーバー側がランタイムエラーでパニックを発生させるのは根本的に問題がある。単にエラーを返すべき。

**デフォルトの名無しさん** · 2025/06/16(月) 19:53:50.09

Rustは絶対安心安全なんだよ

**デフォルトの名無しさん** · 2025/06/16(月) 22:35:10.42

>>827
もちろんあるべき姿としてはエラーを返すなりフォールバックさせるなりすべき
だけど現実はヌルポでエラーも返さずクラッシュさせてたわけでRustに置き換えればpanicで落としてたのと同じようなもの

つまりRustを使っていれば防げたかというと今回のケースは防げなかった可能性が高いということ

**デフォルトの名無しさん** · 2025/06/16(月) 23:23:51.15

Rustを使えば防げただろう

**デフォルトの名無しさん** · 2025/06/16(月) 23:25:29.39

>>824
そういう時はこれ

[lints.clippy]
unwrap_used = "deny"

**デフォルトの名無しさん** · 2025/06/17(火) 07:28:54.01

>>829
ならpanicさせる>823の考えは間違いだね。

rustも安全性を標榜するならpanic禁止モードを用意すべきだわ。

**デフォルトの名無しさん** · 2025/06/17(火) 08:53:29.58

DoS攻撃脆弱性でregexのCVEがあったけど
関連サービスの事を無視して自分勝手にpanicしちゃったら同じ脆弱性だよね

**デフォルトの名無しさん** · 2025/06/17(火) 09:28:01.71

ヌルポ騒動が起きるたびにRustの重要性が引き上がる

**デフォルトの名無しさん** · 2025/06/17(火) 09:35:12.84

>>834
ポリシーの内容をチェックして。受け入れ可能じゃなければResultでテキトーにErr返したら済んだんじゃないの？

パニックさせる必要ほんとにあったと思ってる？

**デフォルトの名無しさん** · 2025/06/17(火) 10:10:19.32

>>835
それでもこの件では障害になることには違いないのでは
クラッシュはしないかもしれないが

**デフォルトの名無しさん** · 2025/06/17(火) 10:27:20.42

Rustで書くなら関数は必ずResultもしくはOptionを返すことになり、上位で処理される

**デフォルトの名無しさん** · 2025/06/17(火) 10:32:24.66

>>837
>>822にもあるけど
> Optionをunwrapしていいのは常にSome自明時と
その「自明」をコンパイラが静的分析するか>>831がデフォルトじゃないかぎり
隠れ unsafe

**デフォルトの名無しさん** · 2025/06/17(火) 10:35:09.70

>>838
unwrapは使われない
?オペレータで上位へ委託するか
match / if let等で処理される

**デフォルトの名無しさん** · 2025/06/17(火) 10:41:17.77

このGoogleの件に関して言うなら、ポリシーの読み込み失敗即ちロールバックなんだろうからpanicは妥当
起動時に必須の環境変数が無い場合にpanicさせるようなもんだね

**デフォルトの名無しさん** · 2025/06/17(火) 10:46:12.73

panicで全体を止めたくない時はUnwindSafeな処理単位をcatch_unwindで実行すればいい
使ったことないけど

**デフォルトの名無しさん** · 2025/06/17(火) 10:51:31.79

>>832
ヌルポでクラッシュさせてたのは間違いではなかったとでも？

>>823はヌルポでクラッシュさせてた人たちの認識
その人たちが仮にRustを使ってたら同じようにpanicで落とすだけ
つまりRustを使っていたとしても障害は防げないという話

それに今回の障害を見てエラーハンドリングしていれば問題なかったと考えるのは短絡的すぎる
一番の問題点は一サービスの一コンポーネントがクラッシュしただけであらゆるサービスが全面的にダウンしたという点にある
だからあらゆるコンポーネントを絶対panicしないように作ろうとするよりも一コンポーネントがpanicしたとしても全面的なシステムダウンに繋がらない仕組みを作ろうと考えることが今回のような障害を防ぐための第一歩

**デフォルトの名無しさん** · 2025/06/17(火) 10:56:21.14

>>842
まともなシステムはそれだな
プロセスが落ちてもハンドリングされる

**デフォルトの名無しさん** · 2025/06/17(火) 10:58:00.04

異常状態のままプロセスが走り続けるよりもpanicなどでプロセス終了が正しいシステム構築

**デフォルトの名無しさん** · 2025/06/17(火) 11:09:29.63

異常状態のまま動き続ける言語よりさ
panic or エラー処理されるRustが良い結論は変わらんよね

**デフォルトの名無しさん** · 2025/06/17(火) 11:13:48.44

>>842
Google Cloud APIのコントロールプレーンのコアコンポーネントはさすがに一サービスの一コンポーネントとかいうレベルじゃないよ
OSのカーネルみたいなもん
こんなのヘタに誤動作を続けられたら会社が吹き飛ぶようなセキュリティ事故に繋がる可能性もあるわけで、死んでくれた方がマシ

**デフォルトの名無しさん** · 2025/06/17(火) 11:52:15.15

ワンワンパニック

**デフォルトの名無しさん** · 2025/06/17(火) 12:50:17.15

Javaで
if (value == null) {
throw AppException();
}
を書き忘れるのとRustで
let Some(value) = opt_value else { return Err(AppError); }
の代わりに
let value = opt_value.unwrap();
と書くのは発生リスクが全然違うと思うんだけど
Javaでうっかりnullチェックを忘れる人はRustでもうっかりunwrapを使うものなのか？

**デフォルトの名無しさん** · 2025/06/17(火) 13:10:12.25

>>848
本人判断で「自明」と決めつけて意図的にunwrapを使うのでは

**デフォルトの名無しさん** · 2025/06/17(火) 13:36:52.80

>>822によれば
本人判断で「panicで落ちていい」と決めつけて意図的にunwrapを使うパターンもある

**デフォルトの名無しさん** · 2025/06/17(火) 14:21:36.03

>>848
Rustでは必要により明示的にpanicさせる.unwrap()とコードを書いた時のみpanicが起きる
意思が必要

**デフォルトの名無しさん** · 2025/06/17(火) 15:48:15.44

>>846
クラッシュしたのはコントロールプレーンの一部であるポリシーチェックシステムのさらにその一部のバイナリ
もっと言えば問題が起きたのはそのまた一部のクォータチェック部分

クォータチェックができなければGCPの全サービスを落とすべきというビジネス判断としてはなくはないがIncident Reportを見る限りGoogleはそうは考えてない

**デフォルトの名無しさん** · 2025/06/17(火) 16:05:37.54

Rustにしとけ
続行不可能で意図的にpanicさせるか
きちんとResult/Option処理するかになる

**デフォルトの名無しさん** · 2025/06/17(火) 16:27:46.74

リリースしてから実際にポリシー変更が発生するまでの2週間、
テストやりこんで最後のバグだしするまでの時間とみなすか、
リリースヨシ！と思ってたかだよな

リリース後も2週間頑張ってテストやったけど境界条件探すの下手くそで見つけられませんでした、で通るかな。自分のことのようにゾッとする

**デフォルトの名無しさん** · 2025/06/17(火) 17:05:59.65

>>854
プログラムの変更とポリシーデータの変更は責任者も管轄組織もプロセスも違うんだと思う
ポリシーデータのほうはビジネスよりの組織が管轄というのはよくある話
なのでDev的にはリリースヨシ！

改善点の2点目に「Regardless of the business need for ～」とあるからOpsはBizの政治力で本来とは違うプロセスを強制させられたのかもしれない

**デフォルトの名無しさん** · 2025/06/17(火) 18:12:51.30

ここに内部事情を含めていろいろ書いてあった
https://news.ycombinator.com/item?id=44274563

**デフォルトの名無しさん** · 2025/06/18(水) 00:29:09.64

ここでの議論と同じだね
Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ

**デフォルトの名無しさん** · 2025/06/18(水) 01:06:16.44

>>857
>Rustでpanicするの明示的にpanicを起こすコードを書いたときだけ

ここでもHNでもそんな議論はされてない
ただ複オジが連呼してるだけ

**デフォルトの名無しさん** · 2025/06/18(水) 01:09:01.01

さっさとC++捨ててRustにすれば防げたのにな

**デフォルトの名無しさん** · 2025/06/18(水) 01:12:36.99

>>858
初心者は今回のこのまとめを見るといい
https://news.ycombinator.com/item?id=44281839

**デフォルトの名無しさん** · 2025/06/18(水) 02:58:44.97

Googleの事案なんてどうでもよくてインシデントにかこつけてRustの布教がしたいだけ
だから何を書いても無駄

**デフォルトの名無しさん** · 2025/06/18(水) 06:20:38.83

Rustを採用していれば防げた事案

**デフォルトの名無しさん** · 2025/06/18(水) 09:57:10.50

>>848
本質は同じ

書き忘れではなくロジカルな思い違いもある
ここでnulｌはないやろとここErrはないやろは同じで思い込みだから

言語によって優劣とかじゃなく人間の限界がある

**デフォルトの名無しさん** · 2025/06/18(水) 10:09:02.91

>>863
全く違う
unwrap()はNone時にpanicを起こすための関数
書き忘れでpanicしない

**デフォルトの名無しさん** · 2025/06/18(水) 10:20:51.18

＞　書き忘れではなくロジカルな思い違いもある

**デフォルトの名無しさん** · 2025/06/18(水) 10:31:14.78

panicさせてはいけないプログラムでpanicさせる関数を呼ぶバカはいない
reviewでもバレる

**デフォルトの名無しさん** · 2025/06/18(水) 10:49:25.62

メモリリークさせてはいけないぷろぐらむでめもりりーくさせるばかはいない！

**デフォルトの名無しさん** · 2025/06/18(水) 11:01:39.66

Rustを使えばメモリリークも未定義動作もなく安全安心よ

**デフォルトの名無しさん** · 2025/06/18(水) 11:23:14.90

haskellと比べて、unwrapが気軽に使えすぎる気はする

**デフォルトの名無しさん** · 2025/06/18(水) 11:33:39.23

ErrやNoneの時にpanic!を呼びたい場合が多いからunwrapがある
呼びたくないのに使うのは痴呆

**デフォルトの名無しさん** · 2025/06/18(水) 11:34:34.48

index out of boundsやdivide by zeroをはじめ意図せずpanicを起こすケースなんていくらでもある

**デフォルトの名無しさん** · 2025/06/18(水) 11:39:44.34

panicはcatchできるし
そのthreadが死ぬだけだし
困らんよな

**デフォルトの名無しさん** · 2025/06/18(水) 11:43:26.69

>>871
panic禁止のプログラムのためにpanicしない方法が用意されていますよ
勉強しましょう

**デフォルトの名無しさん** · 2025/06/18(水) 11:45:58.97

>>860
視野の狭い末端プログラマーの視点だな
システム全体が見えていない

**デフォルトの名無しさん** · 2025/06/18(水) 11:46:56.90

>>873
視野の狭い末端プログラマーの視点だな
システム全体が見えていない

**デフォルトの名無しさん** · 2025/06/18(水) 11:50:22.96

>>874
落ちてはいけないシステムをUB地雷だらけのC++で書くことが愚か

**デフォルトの名無しさん** · 2025/06/18(水) 11:52:41.70

>>875
Rustのスレでシステム全体って何やねん
説明してみ

**デフォルトの名無しさん** · 2025/06/18(水) 12:16:05.81

「意図したpanic」禁止したら良い
その「意図」が正しいのかコンパイラが静的分析出来ないから

**デフォルトの名無しさん** · 2025/06/18(水) 12:29:52.79

>>878
panicはプログラムやスレッドが続行不可能な時に正しく終了させるためにあります
禁止は困ります

**デフォルトの名無しさん** · 2025/06/18(水) 13:09:11.05

mseditorがpanicしたら編集中のデータが飛ぶけど、それが「正しく終了」か？

**デフォルトの名無しさん** · 2025/06/18(水) 14:28:18.37

ヌルポやバッファオーバーランに比べれば比較的マシ

**デフォルトの名無しさん** · 2025/06/18(水) 15:01:02.42

意図的ヌルポでセグフォと
意図的unwrap panicでabortは同じ

**デフォルトの名無しさん** · 2025/06/18(水) 15:13:41.28

会社の怖い先輩が俺のコードはunwrapでいいんだよと言ったら、そうするしかないよね

**デフォルトの名無しさん** · 2025/06/18(水) 15:24:13.90

まさかとは思うがnullチェックしてれば防げた障害だと思ってるやつがいるのか？

**デフォルトの名無しさん** · 2025/06/18(水) 15:37:47.95

ぬるぽでクラッシュしたと聞いたけどnullチェックで防げないぬるぽってあるんすか

**デフォルトの名無しさん** · 2025/06/18(水) 15:49:01.71

今どきC++で新たなコードを書くから悲惨な事故が起きた

**デフォルトの名無しさん** · 2025/06/18(水) 16:01:28.34

>>884
Rustなら防げたと言ってるあのおじさんを除けばそこまてのバカはいないかと

**デフォルトの名無しさん** · 2025/06/18(水) 16:01:44.34

設定がおかしい場合の例外処理フローはあったけどそこに入る前にぬるぽで爆死した認識

**デフォルトの名無しさん** · 2025/06/18(水) 16:35:49.37

RustならコンパイラがAIよりも厳密なチェックをしてるから防げるだろ

**デフォルトの名無しさん** · 2025/06/18(水) 17:03:37.08

Rustは言語仕様が優れているけど
言語仕様が腐っていればAIでも防げない

**デフォルトの名無しさん** · 2025/06/18(水) 17:43:59.13

世界最長のコンテキストウィンドウ100万トークン入力・8万トークン出力対応にもかかわらずたった7800万円でトレーニングされたAIモデル「MiniMax-M1」がオープンソースで公開され誰でもダウンロード可能に
2025年06月18日 11時43分
https://gigazine.net/news/20250618-minimax-m1-open-source/
>>MiniMax-M1は、合計4560億のパラメーターが含まれており、トークンごとに459億のパラメーターがアクティブになるとのこと。これはDeepSeek R1の8倍に相当するコンテキストウィンドウです
>>以下のグラフは競技レベルの数学、コーディング、ソフトウェアエンジニアリング、エージェントツールの使用、長文理解タスクにおけるパフォーマンスを主要な商用AIモデルと比較したもの。赤色がMiniMax-M1で、どのタスクにおいても競合AIモデルに匹敵するパフォーマンスを発揮できている
>>MiiniMax-M1はいくつかのベンチマーク、特に長いコンテキスト駆動のベンチマークでClaude Opus 4のパフォーマンスを上回りました」と報告
※AIを動作させている動画あり
↓上記のAIお下記をプレイさせれば性能が判明する
Gemini 2.5 Proは手持ちのポケモンが瀕死になるとパニックに陥る
2025年06月18日 12時30分
https://gigazine.net/news/20250618-pokemon-gemini-panic/
◇
[プロテクトガードやセキュリティーホール発見可能]
※1 プログラムのバグ技[裏抜け道]を使用できる＝チートコードを発見可能
・マリオカートのショートカットはプレイヤー「極悪人」の表の抜け道でNPC「一般人」は使用不可能
[インサイダー/談合/なねーロンダリング/霊感商法など行う時の悪行で音波や電波をしての悪行の方法を発見可能
※ 政治家の法律上の抜け道を仕込める＝ある業種だけの法律の抜け道を発見可能
[一般大衆の思考である特定の極悪人から目線を特定の統合失調症へ返させる装置]
※ ＡＩは正確な情報で人間を信用させれる＝ＡＩは嘘の情報を一部混ぜて人間を洗脳できる

**デフォルトの名無しさん** · 2025/06/18(水) 18:45:36.06

まさかとは思ってたがnullチェックで防げたと勘違いしてるやつ結構いるんだな

**デフォルトの名無しさん** · 2025/06/18(水) 19:12:39.40

＞読み込みデータに空白フィールドがあり、これがヌルポインタとなって参照した時点でクラッシュを引き起こした。

**デフォルトの名無しさん** · 2025/06/18(水) 20:36:14.97

OptionやResultの型をきっかけとして問題に気付けた可能性はあるんじゃない？
あくまで間接的な可能性でしかなく、この件をもってRustだったら起きなかったとかいうのはアホ丸出しだけども

**デフォルトの名無しさん** · 2025/06/18(水) 20:49:33.05

Rustなら上位へそのエラー返して
その入力データに対するAPIでエラー返すだけだろ

**デフォルトの名無しさん** · 2025/06/18(水) 22:27:10.05

>>894
いいかげんにしろよ
Rustでどうやって問題が起きるんだよ

**デフォルトの名無しさん** · 2025/06/18(水) 22:47:29.81

この件については、クラッシュを回避しエラーレスポンスを返したところで結局障害になることには違いがないからだな

**デフォルトの名無しさん** · 2025/06/18(水) 22:51:57.91

>>894
間接的な可能性もないでしょ

**デフォルトの名無しさん** · 2025/06/18(水) 23:03:07.16

>>897
Googleのレポート見ろよ
エラーを返せていれば障害にならなかった

**デフォルトの名無しさん** · 2025/06/18(水) 23:18:21.28

>>899
そんなことどこにも書いてないぞ
エラーを返していればなんで障害にならないんだ？
回復不能なエラーだぞ

**デフォルトの名無しさん** · 2025/06/18(水) 23:25:54.18

Rustなら回避できたケースだけど
無理！と言う人は具体的に無理なシナリオを示してみたら？

**デフォルトの名無しさん** · 2025/06/18(水) 23:41:41.61

ワロ
理解できないから教えてくれと言えばいいものを

**デフォルトの名無しさん** · 2025/06/18(水) 23:53:20.04

公式読めよ
Rustにしてればポリシー変更データをエラーにして受け付けず落ちることもなく被害なし

**デフォルトの名無しさん** · 2025/06/19(木) 00:10:11.24

設定のミスで１台のATMが使えなくなるか全部のATMが使えなくなるかみたいな話でしょ
どっちも障害だから同じだって考え方もあれば
障害を１台に抑えることに価値があるって考え方もある
Rustでも防げないって人は前者だしRustなら防げたって人は後者
どっちの考え方もそれなりに正しい

**デフォルトの名無しさん** · 2025/06/19(木) 00:25:10.66

>>897
exponential backoffが実装されてなかったから
リクエスト単位のエラー返しにしてた場合は
復旧にもっと時間がかかってたと思われる

かといってC++でヌルポはだめだけどな

**デフォルトの名無しさん** · 2025/06/19(木) 00:48:27.34

>>905
新たなポリシー変更要求がエラーで受け付けられなくて落ちることもないから障害が起きていない

**デフォルトの名無しさん** · 2025/06/19(木) 01:27:03.00

>>906
どこにそんなこと書いてる？
新しいポリシーがSpannerに書かれてレプリケートされた後の話だろこれ

**907** · 2025/06/19(木) 01:37:22.30

ああ、もしかしてポリシーのチェックというのをポリシー自体のバリデーションと勘違いしてるのかな
正しくはポリシーに基づいてAPIリクエストをチェックする処理のことなんで、新しいポリシーが反映された結果としての障害だよ

**デフォルトの名無しさん** · 2025/06/19(木) 01:38:01.02

>>904,906
君は何を言ってるんだい？
Googleのレポート見ろよ&&公式読めよブーメランが刺さってるぞ

**デフォルトの名無しさん** · 2025/06/19(木) 02:14:01.17

>>908
新しいポリシーを反映させないか
反映させても空白のみエラーで飛ばせば障害は起きていない

**デフォルトの名無しさん** · 2025/06/19(木) 04:21:35.41

Rustにしとけってことか、速い話が

**デフォルトの名無しさん** · 2025/06/19(木) 05:04:25.47

落ちるプログラムを各リージョンにバラ撒かなければ何製でも防げてる
もちろんRustなら確実に防げた

**デフォルトの名無しさん** · 2025/06/19(木) 06:59:17.36

とにかくRustにすれば安心安全
これはもう常識

**デフォルトの名無しさん** · 2025/06/19(木) 11:59:43.17

ちゃんとした人が、Rustを使った場合に限る。
セキュリティもそうだけど、人が関わると碌なことがない。

**デフォルトの名無しさん** · 2025/06/19(木) 12:27:53.31

Rustは安全に配慮したコンセプトはいいけど、それを徹底できていない。
せめてSafe Rust強制モードとpanic禁止モードは用意しておくべきだった。

**デフォルトの名無しさん** · 2025/06/19(木) 21:29:19.19

CPUとメモリは自由なunsafeが本質なので下位のライブラリは標準もデファクトもunsafeで作られている

**デフォルトの名無しさん** · 2025/06/19(木) 21:38:06.06

panicは意図せず混入防止も兼ねてこんな運用が多いかな
[lints.clippy]
missing_panics_doc = "warn"

**デフォルトの名無しさん** · 2025/06/19(木) 21:49:11.90

標準ライブラリが内部では unsafe だらけというのは確かにそう。
外側に対しては安全になるように配慮してるけど、バグが絶対にゼロかというとそんなことはないし、実際に発見されたこともある。
まあ unsafe に限らず処理系や標準ライブラリにバグがあることを疑ってたらきりがないからそこらは割り切らないと仕方なくない？

**デフォルトの名無しさん** · 2025/06/19(木) 21:56:40.37

みんな律儀にResultは全てちゃんとハンドリングしてるの？
Mutex.lock() なんかは気にせず unwrap してるんだけど

**デフォルトの名無しさん** · 2025/06/19(木) 22:11:01.42

>>919
ロックが失敗するのはスレッドがパニックしたとき。
つまりハンドリングするならそのスレッド内のエラーであるべきで、 Mutex.lock の失敗に対してハンドリングしても出来ることがない。
そこは普通は unwrap してよいところだと思う。

**デフォルトの名無しさん** · 2025/06/19(木) 23:34:30.87

そのmutex毒入り状態からの復帰処理をしたい場合はunwrapせずにErr時に処理とclear_poison()する

**デフォルトの名無しさん** · 2025/06/20(金) 00:31:53.70

これおもしろー

https://blog.guillaume-gomez.fr/articles/2025-06-19+Rust%3A+Optimizing+integer+to+string+conversions

ポインターアクセスより配列の方が速いんやー

**デフォルトの名無しさん** · 2025/06/20(金) 01:02:39.89

unwrapではなくexpectを使う。

**デフォルトの名無しさん** · 2025/06/20(金) 01:08:46.49

>>923
いや、Optionにはunwrap使ってええんやで
コードに合わせて柔軟に対応すりゃバグは防げるよ
ビジネスロジックのバグは入念なテストしないと見つけられないけどね
ビジネスロジックのバグでシステム障害になることもまあ、あるっちゃあるよねテストしてなきゃ

**デフォルトの名無しさん** · 2025/06/20(金) 01:13:11.37

>>922
昔読んだが00～99のテーブルをコピーするところだな
配列境界検査は起きないコードだから速度は同じ

**デフォルトの名無しさん** · 2025/06/20(金) 01:18:17.09

>>924
panic許容シーンでない場合
絶対Some保証できない場ではunwrapもexpectも使わないよな

**デフォルトの名無しさん** · 2025/06/20(金) 07:50:16.10

expectに書く文がいまいち分からんのだよな
エンドユーザーがその一文だけ見て何か意味があるとも思えないし
デバッグする開発者向けなら結局前後の文脈込みで見るしかないから
unwrapにして詳細をコメントに書いたほうがいい気がしている

**デフォルトの名無しさん** · 2025/06/20(金) 08:04:54.66

>>927
ユーザに文章を示してpanicさせたいの？
文章をprintかeprintしてからpanic!呼んだら？

**デフォルトの名無しさん** · 2025/06/20(金) 08:15:40.44

>>928
いや、そうじゃなくて「unwrapの代わりにexpectを使ってunwrapしても大丈夫な理由を明記すべき」みたいな言説があるじゃん？
そのときにexpectに書くべき文がわからんって話

ユーザ向けにエラーとして表示したいならそりゃ普通にResult使うし、
どうしてもパニックしたいならprintlnすればいいのはその通りだけど

**デフォルトの名無しさん** · 2025/06/20(金) 08:22:37.63

基本フロントエンド側とAPIのエラーコード、エラーメッセ仕様は最初に決めておくから、あとは「どの関数レイヤーで」そのIFに合わせこむかだけじゃない？
ここのスレ多分Rustを業務用で使ってる人ばっかだから仕様の取り決めとから雇用主から降ってくるもんだと思うけど。返すエラー定義決まってなきゃそもそもテストコード先に書けないし、納品物にもテスト結果入れれなくて困るしな

**デフォルトの名無しさん** · 2025/06/20(金) 08:25:55.42

個人的にはtracing::debug!で自分用のデバッグ出力はON/OFFしてるけど、エラーコードやエラーメッセージは案件別に全然仕様が違うwwwやめてwwwから、仕方なくErrで一旦上げてresponse.bodyに詰め込む直前で相手さんの期待する結果になるようにparseしてることが多い

フロントエンド側で翻訳ぐらいせえやーって思うけど、たまにバックエンドで各言語に合わせて翻訳やってくれー案件もあったりするしバラバラで何考えてんのかはよー分からん

**デフォルトの名無しさん** · 2025/06/20(金) 09:04:21.71

>>929
https://doc.rust-lang.org/std/error/index.html#common-message-styles
に尽きると思うが、何がわからんのかわからん
原則としては例外ケースが生じない確信があろうとエラーコンテキストは引き継がれるべきで、
panicさせるのは当該ケースの対処のしようがないことがその場で明らかなケースのみ
そして君のコード内でコントロールのしようがない事象である以上は基本的にそれは外部要因によるものだろうから、その要因を記載すればいい

**デフォルトの名無しさん** · 2025/06/20(金) 09:47:50.29

>>932
外部要因ならコード作者は制御できないんだからResultで表現すべきではない？
unwrapするケースって「このコードパスではxは（自分が書いたロジックが間違ってなければ）確実にSomeだから安全にunwrapできるはず」みたいなのだと思うんだけど、
その文をexpectに書いたとして誰が読むんだ？って疑問

**デフォルトの名無しさん** · 2025/06/20(金) 10:32:17.84

panic時のメッセージは未来の自分を含めて他の開発者向け

ここの2つを読んでおくといいと思う
https://burntsushi.net/unwrap/#why-not-use-expect-instead-of-unwrap
https://www.thecodedmessage.com/posts/2022-07-14-programming-unwrap/

**デフォルトの名無しさん** · 2025/06/20(金) 11:10:25.36

開発者向けにコードの意図を説明するのって普通はコメントだと思うんだよね
例えばunsafeを使っても安全な理由とかもコメントで書くし
なのにunwrapに限ってわざわざ文字列リテラルで書く理由が分からない（複数行や長文も書きづらいし）
コメントとの違いは実行時に表示できることではあるけど
実行時にその一文を出せて嬉しいか？
開発者なら結局周辺含めてコード読むんじゃない？

**デフォルトの名無しさん** · 2025/06/20(金) 11:19:56.95

書いてて思ったけど「このメッセージが表示されたらライブラリのバグなんでこのGithubまで報告してね」
みたいなメッセージなら意味あるかな、という気がした
エンドユーザーが見てちゃんと理解できるから実行時に出す意味もあるし、
ライブラリの内部エラーだからアプリケーション側には責任がないことも表明できるし

**デフォルトの名無しさん** · 2025/06/20(金) 11:25:39.91

>>936
これいいな。OSSならそんな感じだしエンタープライズなら開発担当部門書いとこ

**デフォルトの名無しさん** · 2025/06/20(金) 12:33:04.85

バグなんて他にもいくらでもあるんだから、それこそunwrapに限ってそんな懇切丁寧なケアをする理由がない
やらかした犯人なんてgit blameですぐわかる

**デフォルトの名無しさん** · 2025/06/20(金) 13:09:09.82

expectは使用者とか使用状況に対する期待だと思ってた
メッセージはコメントのPanicsに対応させる感じ

/// ...
///
/// # Panics
/// - Panics if the given size is 0.
///
pub fn make_buffer(size: usize) -> Buffer {
let nz_size = NonZeroUsize::new(size).expect("size must be non-zero");
// ...
}

**デフォルトの名無しさん** · 2025/06/20(金) 15:04:20.99

>>939
基本的にはその考え方で正しい。
でも標準ライブラリや処理系すらそうしてないし、現実は理想通りではない。

**デフォルトの名無しさん** · 2025/06/20(金) 16:00:22.03

Haskellにはならなかったな
Rustにもならないのでは？

**デフォルトの名無しさん** · 2025/06/20(金) 16:21:36.04

>>941
Rustは本来的にはコーディングの誤りに対して939のようにわりと問答無用でpanicする指向だと思うけど、
関数型というかHaskellかぶれのオモチャにされてるせいで実行時panicダサいみたいな空気が醸成されてきている一方で、
なんでも型のコンテキストで上手に扱えるほど型に表現力があるわけでもないから中途半端な感じになってるね

**デフォルトの名無しさん** · 2025/06/20(金) 16:41:57.96

システムプログラミング言語としての性質があるから仕方がない面はある。
ハードウェアやら OS やらが Rust の性質に従ってくれるとは限らないので言語の側で合わせないと仕方がない。

**デフォルトの名無しさん** · 2025/06/20(金) 16:53:23.26

Rustバランスいいよな
抽象度の高い記述ができつつC言語の代替もできる

**デフォルトの名無しさん** · 2025/06/20(金) 17:25:54.91

Haskellもボトム型あるから変わらんだろ
どの型の値も計算できない可能性を内包してる

**デフォルトの名無しさん** · 2025/06/20(金) 18:40:08.56

>>936
そういうのはまとめてpanic handlerに書いたほうがいいんじゃないかな
最近はあまり使われてないかもしれないけどhuman-panicとかがそれ用

あとstdのリファレンスにもexpectに書くメッセージのスタイルについて解説があった
https://doc.rust-lang.org/std/error/index.html#common-message-styles

**デフォルトの名無しさん** · 2025/06/21(土) 18:45:15.07

>pub fn make_buffer(size: usize) -> Buffer {
>let nz_size = NonZeroUsize::new(size).expect("size must be non-zero");

事前条件がNonZeroなら
pub fn make_buffer(size: NonZeroUsize) -> Buffer
にしたほうが堅さという意味ではよくない？

**デフォルトの名無しさん** · 2025/06/21(土) 19:54:31.34

外部入力が起源のデータに対しては必ずエラーを返す
プログラム自身発ならバグであり続行不可なのでpanicしてもよい

**デフォルトの名無しさん** · 2025/06/21(土) 19:55:55.14

>>947
NonZeroは非ゼロの保証というよりOptionと一緒に使うためのものだからね
NonZeroにしたところで結局呼び出し元でのチェックが0との比較からOptionのチェックに変わるだけのことでしかなく、
コードが冗長かつ余計なoptionが入ることでノイズが増え意図が不明瞭になるし、
unwrapしちゃったらpanic時のエラーもわかりづらい
ダメってわけじゃないが呼び出し元のことを考えると独善的な感が否めない

**デフォルトの名無しさん** · 2025/06/21(土) 22:49:35.45

>>949
>NonZeroは非ゼロの保証というよりOptionと一緒に使うためのものだからね
Optionと一緒に使うためのものというのはよく意味がわからない

例えばOptionに置き換えて考えてみたとしてこういう実装があったらおかしいと思わない？
fn make_buffer(size: Option<usize>) -> Buffer {
let size = size.expect("size must not be None”)
…
}

簡単に型で表現できないものならまだわかるんだけど

**デフォルトの名無しさん** · 2025/06/21(土) 23:02:46.26

呼び出し元は外部入力なら
let size = NonZeroUsize::new(input_size)?;
let buffer = make_buffer(size);

定数なら
let buffer = make_buffer(NonZeroUsize::new(1024).unwrap());

validation前とvalidation後で型を変えるプラクティスと同じでこっちのほうが望ましいことのほうが多いんじゃないかという気がする

**デフォルトの名無しさん** · 2025/06/21(土) 23:54:32.82

整理されて今はこう書くNonZero::<usize>::new(1024)
いずれにせよ外部データ由来時でもpanicさせ得る>>947は筋が悪い

**デフォルトの名無しさん** · 2025/06/22(日) 00:46:32.15

slice::windowsとかstdでも似たような実装はそれなりにある
pub fn windows(&self, size: usize) -> Windows<'_, T> {
let size = NonZero::new(size).expect("window size must be non-zero");
Windows::new(self, size)
}

windowサイズはバグ以外では0を指定しないだろうという想定だと思うがcalleeとcallerのコードを書く人間が異なっていて認識の齟齬があったりすればバグになるからエルゴノミクスとバグリスクのトレードオフってことになる

**デフォルトの名無しさん** · 2025/06/22(日) 01:30:55.82

docコメントの
///
/// # Panics
///
/// Panics if `size` is zero.
///
とセットで見ないといけない

**デフォルトの名無しさん** · 2025/06/22(日) 09:45:37.71

RAIIが破綻するレベルのパニック、という意味の専門用語があればいいんだよね

**デフォルトの名無しさん** · 2025/06/22(日) 12:30:29.11

・人間の思考「脳波」は頭蓋骨の外に漏れない
人間の脳は発光していた！「脳が放つ光」の観測に初成功
2025.06.19 12:00:38 THURSDAY
https://nazology.kusuguru.co.jp/archives/179808
>>カナダ・アルゴマ大学（Algoma University）の最新研究で、ついにこの「脳の光」を頭蓋骨の外から観測することに成功したのです。
>>UPEは細胞の代謝活動、特に酸化反応によって発生する副産物の一種です。
>>以来、UPEはあらゆる植物や動物の細胞からも確認されており、生体内の酸化ストレスや老化、さらにはがんの診断補助にも応用が期待されてきました。
>>脳は体の中で最も代謝が活発な臓器のひとつであり、神経活動に伴って活性酸素が多く発生します。
>>チームは今回、20人の健康な成人を対象に、特殊な装置を用いた実験を実施しました。
>>被験者は真っ暗な部屋に座り、頭には脳波計を装着。
>>その周囲には、光電子増倍管（PMT）と呼ばれる極微弱な光を検出する装置が配置されました。
>>そして被験者には、目を開ける／閉じる、あるいは音楽（120BPM）を聴くといったシンプルなタスクを行ってもらい、その間のUPEと脳波の変化を同時に測定したのです。
☆>>まず、脳からのUPEは背景光（周囲の空気中のノイズ）とは明確に異なる変動パターンを持つことが判明したのです。
>>とくに後頭部（視覚野）と側頭部（聴覚野）から検出された光は、安静時でも一定のリズムと変動性を示し、他の部位とは異なるスペクトル的特徴を持っていました。
>>さらに目を閉じたときに増える「アルファ波」と呼ばれる脳波の活動と、UPEの強さが同期していることも発見されました。
>>これはつまり、脳の電気的な信号（脳波）と、化学的な代謝反応（UPE）が連動していることを意味します。
>>この成果は、従来のfMRIやPETスキャンのような「重装備で高コスト」な装置を使わずとも、非侵襲・低刺激で脳機能の状態を“光”から読み取る可能性を示すものです。
>>研究者たちはこの新しい手法を「光脳波記録（photoencephalography）」と名付けました。

**デフォルトの名無しさん** · 2025/06/22(日) 12:58:47.51

>>955
パニックのレベルじゃなく処理単位の特性だけどUnwindSafeがある

**デフォルトの名無しさん** · 2025/06/22(日) 23:16:05.62

無限ループがあれば、終了しないスレッドや呼ばれないデストラクタもありうる
bottomもabortもpanicも、無限ループよりはマシだから禁止されない

**デフォルトの名無しさん** · 2025/06/22(日) 23:59:22.53

exitよりもpanicが優れている
多くのメリットがある

**デフォルトの名無しさん** · 2025/06/23(月) 15:14:34.98

無職や転職をしたい
上記の方を紹介していただけませんか？

誰でも歓迎❣
未経験でも40歳まで採用しています⭕

ぜひご相談ください🙏

https://i-c-i.jp/members/

電話番号
03-6459-0063

**デフォルトの名無しさん** · 2025/06/23(月) 15:14:44.43

株式会社アイ・シー・アイ
野村総合研究所が設立した、信頼と実績のあるIT企業です。
未経験でも大丈夫！40歳までの方ならどなたでもご応募いただけます。
日本の大手大企業のソフトバンク、キャノングループ、富士産業で働けます！
雇用形態は無期雇用派遣。一つの現場で最低5年間じっくりインフラ運用監視の経験が積めます。

年収は280万円、賞与は年3回と安定した待遇をご用意し、「社員の人生を幸せにするため」の福利厚生も充実しています。

当社はまだまだスタートアップ。数年後には事業規模、
会社規模を倍増させたいと考えています。
その際、あなたには会社の中核メンバーとして、一緒に会社を引っ張っていただきたいのです。

**デフォルトの名無しさん** · 2025/06/23(月) 18:22:32.34

人売りの奴隷集め

**デフォルトの名無しさん** · 2025/06/23(月) 21:09:50.86

Z世代の皆様にしっかり稼いで頂きたいという思いから、高収入案件をご紹介させていただいております。

**デフォルトの名無しさん** · 2025/06/24(火) 22:23:36.74

Rustへ移行のためのドキュメント「C++ to Rust Phrasebook」発表
https://techfeed.io/entries/683ccb678fc2c0556f0d68d0

C++でおなじみのイディオムや設計パターンを、Rust流にどのように書き換えるかを体系的に示したリファレンスである。
各章は具体的なコード例と、それに伴う設計上のトレードオフについての解説で構成される。
「C++ならこう書くがRustでは？」と行き詰まった場面で索引的に参照する使い方も想定されている。

**デフォルトの名無しさん** · 2025/06/25(水) 23:33:16.67

>>964
「C++ to Rust Phrasebook」
https://cel.cs.brown.edu/crp/

**デフォルトの名無しさん** · 2025/06/26(木) 23:30:50.97

https://facet.rs/

**デフォルトの名無しさん** · 2025/06/27(金) 22:34:08.47

所有権を返すfoo()で&foo()をそのまま使える時と
エラーとなるためlet tmp = foo(); してから&tmpを使わされる時と
temporary lifetime extensionルールが関係しているの？

**デフォルトの名無しさん** · 2025/06/27(金) 23:03:36.64

>>967
おそらくそうだけどコード見ないことには何とも

**デフォルトの名無しさん** · 2025/06/28(土) 00:59:51.80

躁鬱が激しいな

**デフォルトの名無しさん** · 2025/06/28(土) 13:45:14.63

つるつるわれめ

**デフォルトの名無しさん** · 2025/06/28(土) 21:59:50.08

RPITでもTAITでもないimpl Traitは何と呼ばれているの？

**デフォルトの名無しさん** · 2025/06/29(日) 02:06:59.79

Announcing Rust 1.88.0
https://blog.rust-lang.org/2025/06/26/Rust-1.88.0/

**デフォルトの名無しさん** · 2025/06/29(日) 02:41:16.16

>>964-965
boost使いまくってたら

**デフォルトの名無しさん** · 2025/06/29(日) 02:43:51.09

わろす
https://uchan.hateblo.jp/entry/2018/08/24/234334

**デフォルトの名無しさん** · 2025/06/29(日) 03:42:04.63

まだ中３女子がいた時代か…

**デフォルトの名無しさん** · 2025/06/29(日) 23:21:46.38

>>972
便利になったなー

if let Channel::Stable(v) = release_info()
　&& let Semver { major, minor, .. } = v
　&& major == 1
　&& minor == 88
{
　println!("`let_chains` was stabilized in this version");
}

**デフォルトの名無しさん** · 2025/06/30(月) 21:42:35.77

if文を分けなくてよくなったんか
letした変数を次の条件で使えるのは便利だな

**デフォルトの名無しさん** · 2025/06/30(月) 23:28:37.87

let else でもチェーンできるのかな

**デフォルトの名無しさん** · 2025/07/01(火) 01:45:34.56

let chainとかtryブロックとか時間かかりすぎで将来が心配

**デフォルトの名無しさん** · 2025/07/01(火) 08:40:30.66

ぶっちゃけクソsyntaxだろw

**デフォルトの名無しさん** · 2025/07/01(火) 08:56:09.16

プログラミングしたことある人ならば
>>976のようなケースがよく出てくることがわかる
この構文がないと多段ifで可読性が落ちる

**デフォルトの名無しさん** · 2025/07/01(火) 13:13:02.59

むしろなんで最初から用意しようとしなかったのか不思議で仕方がない機能

>>976の例は説明用とはいえ中の人がSemverをChannelで包むのはいただけない

**デフォルトの名無しさん** · 2025/07/01(火) 23:18:30.26

>>976
最近まともな進化がなかったが、久しぶりにいい変更点が来た感じする

**デフォルトの名無しさん** · 2025/07/02(水) 08:10:37.08

ガイジプログラマーだけど質問あるガイジ？
ガイジガイジガイジ死んだ方が良いガイジ地頭悪いガイジ
死ぬガイジ虚言だから死なないガイジガチで死んだ方が良いガイジ

**デフォルトの名無しさん** · 2025/07/02(水) 08:12:19.09

後輩が気を使って僕に席を譲ってくれたガイジ…死んだ方が良いガイジ…死にたいガイジ…

**デフォルトの名無しさん** · 2025/07/02(水) 14:18:35.20

>>976
if文の途中でパターンマッチングできてlet等で変数宣言できるようなプログラミング言語は他にありますか？

**デフォルトの名無しさん** · 2025/07/02(水) 15:55:37.03

>>984
ガイジガイジよいしょよいしょ

**デフォルトの名無しさん** · 2025/07/02(水) 18:49:24.09

>>986
いくらでもあるだろｗ
なんでそれをRustスレで聞くんだよ
複…、バカなの？

**デフォルトの名無しさん** · 2025/07/02(水) 21:26:49.42

>>986
LISP 系や ML 系だと出来るのが多いと思う

**デフォルトの名無しさん** · 2025/07/02(水) 21:52:14.46

>>986
今回の>>976のようなif条件内で連鎖できる言語はないが単純なものならある

**デフォルトの名無しさん** · 2025/07/02(水) 21:56:06.59

C#でもisで出来るでしょ？もちろん&&でつなげられる

**デフォルトの名無しさん** · 2025/07/02(水) 22:41:30.16

みなさんおわかりだろうか
>>976
↓
>>986
↓
>>990

**デフォルトの名無しさん** · 2025/07/02(水) 22:47:53.08

C#はようやくリストのパターンマッチングができるようになったところ

**デフォルトの名無しさん** · 2025/07/02(水) 23:40:48.12

>>982
仕様を定めるため慎重に議論されてきた
糖衣構文が定められたが既存のdrop順序と合わないと判明した
今年からのRust 2024 editionで新たに定めることで解決してこのたび導入された

**デフォルトの名無しさん** · 2025/07/03(木) 00:15:02.16

>>992
本人以外全員分かってると思う

そして…

**デフォルトの名無しさん** · 2025/07/03(木) 11:05:56.13

時は動きだす

**デフォルトの名無しさん** · 2025/07/03(木) 11:33:08.05

シンタックスシュガーだから中途半端なんだよな

**デフォルトの名無しさん** · 2025/07/03(木) 16:19:31.79

パターンマッチングはユニフィケーションにまで発展しないかね。

**デフォルトの名無しさん** · 2025/07/03(木) 19:28:59.84

>>986
Perl最強だぞ

**デフォルトの名無しさん** · 2025/07/03(木) 19:58:10.70

おわり

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 36日 10時間 26分 35秒

**1002** · Over 1000

5ちゃんねるの運営はUPLIFT会員の皆さまに支えられています。
運営にご協力お願いいたします。

───────────────────
《UPLIFT会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
4 USD/mon. から匿名でご購入いただけます。

▼ UPLIFT会員登録はこちら ▼
https://uplift.5ch.net/

▼ UPLIFTログインはこちら ▼
https://uplift.5ch.net/login