[過去ﾛｸﾞ] Win32API質問箱 Build125 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
348: 2019/09/18(水)20:00 ID:Dukdxvvo(3/4) AAS
はい完成品なしｗ
349: 2019/09/18(水)20:07 ID:+0ud2Fjw(4/6) AAS
>>347
それも既に試しましたが同じ結果です
>>341でも書きましたがメッセージを追ってWM_CLOSEが正常な事も確認済みです
350: 2019/09/18(水)20:10 ID:Dukdxvvo(4/4) AAS
はいBASICからやり直しｗ
351: 2019/09/18(水)20:10 ID:+0ud2Fjw(5/6) AAS
>>347
途中送信すみません
設定してもいない値0xfeeefeeeになるので
間隔はSystemと同じ値(500)にSetするだけにしてみても同じ結果でした
352(1): 2019/09/18(水)20:12 ID:rjYHNvyN(1/3) AAS
0xfeeeってデバッグの時の初期化されてない奴の値じゃないっけ
終了時に数値の参照先おかしくなってるとかかな
353(2): 2019/09/18(水)20:31 ID:VIgnmm9s(1) AAS
「あなたのアプリがWM_CLOSEで0xfeeefeeeにしてる」のは明白でしょ
0xfeeefeeeって特別な値よ、ググってみそ
354(1): 蟻人間 ◆T6xkBnTXz7B0 2019/09/18(水)20:50 ID:d3y9L0GY(1) AAS
DestroyCaretしてないとか？
355(2): 2019/09/18(水)20:51 ID:doMp/Sm3(1) AAS
DEBUGビルドのランタイムで
newからのdelete や malloc からの free の後に 確保領域の内容を0xfeee で埋める
ポインタを開放した後に指し先の内容値を取得し、セットしちゃってるんでないの？
356(1): 2019/09/18(水)20:51 ID:nSTUFOvJ(1) AAS
速度設定するとこにトレース出力でもおいて、まずはほんとに意図しないタイミングで呼ばれてないのかチェックだな
357(1): 2019/09/18(水)20:54 ID:GIOjMe2C(1) AAS
イベントを2回通っていて、認識できてないとか。
358(1): 2019/09/18(水)21:32 ID:+0ud2Fjw(6/6) AAS
>>353
キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました
>>354
してもしなくても同じ結果になります
>>355
値の指定をハードコードにしても同じでした
>>356-357
重複した呼び出しなども無かったです
359: 2019/09/18(水)21:52 ID:8Lx1p1Xb(1) AAS
Releaseモードで検証したら
360: 2019/09/18(水)21:58 ID:rjYHNvyN(2/3) AAS
別のとこでメモリ壊してるんかな
その部分だけの最小コード書いてみては
それでもなるなら手に負えない感じが
361(1): 2019/09/18(水)22:24 ID:Ei+Tp6td(1) AAS
>>352-353 >>355
0xfeee なんてパターンあったっけ？
0xFDFDFDFD No man's land (normally outside of a process)
0xDDDDDDDD Freed memory
0xCDCDCDCD Uninitialized (global)
0xCCCCCCCC Uninitialized locals (on the stack)
の４パターンしか知らんかったわ
外部ﾘﾝｸ:docs.microsoft.com
362: 2019/09/18(水)22:31 ID:rjYHNvyN(3/3) AAS
なかったっけ
うろ覚えで書いたから間違ってたかな
363(1): 2019/09/18(水)22:48 ID:u5s3196f(2/3) AAS
0xfeeefeeeでググれ
364: 2019/09/18(水)22:51 ID:u5s3196f(3/3) AAS
>>358
> キャレット関係の終了処理をWM_LBUTTONDOWNのタイミングに変更した時に
> WM_CLOSEの方のキャレット関係の終了処理はコメントアウトしました
マウスクリックで終了してる「はず」なのに終了してないなら、そもそもキャレット処理を
全く走らせてなくても問題が再現する「はず」
でもその場合は問題ないってなら、やはり終了処理に何かある
365(1): 2019/09/19(木)04:56 ID:WgtBHfjG(1/3) AAS
>>363
お前がググれよw
366(2): 2019/09/19(木)08:37 ID:55mEbAq6(1/2) AAS
>>361
new -> delete -> 値が0xfeeefeeeに
もしnewしたクラスのメンバ変数が値を保持して間隔設定してるなら
delete後に0xfeeefeeeなるよ
クラスポインタをdeleteしてからNULLにしたらエラーになるはず
こんな感じじゃないかな
WM_CLOSEで(deleteしてから)DestroyWindow (クラスポインタとメンバ変数の値が0xfeeefeeeに)
→WM_KILLFOCUSでOFFへ (OFFにする時に参照してるメンバ変数が0xfeeefeee)
→プロセスが終了
でもハードコードでもなるみたいだから違うかも？
367(1): 2019/09/19(木)09:42 ID:BhEGNWlU(1/2) AAS
unix の pipe は双方向だと思うのですが
win32api の pipe (namedpipe ではない方) は一方通行なんでしょうか？
先生なんとかなりませんか？
368: 2019/09/19(木)09:45 ID:VunEY3BQ(1/3) AAS
WM_CLOSE
↓
WM_DESTROY
369: 2019/09/19(木)09:51 ID:VunEY3BQ(2/3) AAS
ああ
WM_QUIT
かな
370: 2019/09/19(木)10:17 ID:nEj2AKuG(1) AAS
>>367
UNIXも一方通行では
371(1): 2019/09/19(木)10:35 ID:WgtBHfjG(2/3) AAS
>>366
間隔設定がよくわからんが
class C { int a; };
auto x = new C();
delete x;
ってやるとxのポイント先が0xddddddddになるんだが…
Visual Studio Express 2017, 15.9.16
372: 2019/09/19(木)12:34 ID:WgtBHfjG(3/3) AAS
>>366
書き忘れたけど当然デバッグビルドな
ついでにライブラリのソース追っかけたけどパターンはバイト単位に設定されてるので0xfeeeなんてパターンは無いと思うよ
373(1): 2019/09/19(木)16:05 ID:NIaCYNJC(1/3) AAS
>>365
どこのgoogle使ってんの？
＞0xfeeefeee を検索するとHeapFree で処分された後のヒープ領域がこの値で埋められている、とわかる。 ということは「処分済みヒープへのポインタを誰かが使っている」ということだ。
なお、正解かどうかは論じてないので悪しからず
374: 2019/09/19(木)16:41 ID:cbyVF/Zh(1) AAS
解放バッファの埋めパターンは、ライブラリが自力でセットするものなの？
375: 2019/09/19(木)17:15 ID:BhEGNWlU(2/2) AAS
-D_DEBUGで自動化やろ
376(2): 2019/09/19(木)18:06 ID:NIaCYNJC(2/3) AAS
とりあえず>>373の検証
100バイトHeapAllocして適当にa~zの文字書き込んでHeapFreeの前後でダンプ取ったけど、
0xfeeefeeeが入ることはなかったな
debug版
前
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
後
F0 C6 42 05 88 41 47 05 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00
release版
前
省5
377: 2019/09/19(木)18:13 ID:VunEY3BQ(3/3) AAS
コンパイラによっても違うのか
外部ﾘﾝｸ[html]:www.nobugs.org
378: 2019/09/19(木)18:42 ID:NIaCYNJC(3/3) AAS
APIだからコンパイラ関係ないと思うけどね
OSは8.1だけど
コンパイラというかライブラリが関係するはずのmallocでやってみた
vs2017 - ツールセットvs2013（詳細略）
以下並びは>376と同じだけどダンプの長さはa~zの26+1バイトじゃなく30バイト
allocも100ではなく30バイト
debug
61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 00 CD CD CD
DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD
release
省2
379(1): 2019/09/19(木)19:23 ID:55mEbAq6(2/2) AAS
>>371
間隔設定はキャレットのね
こっちでは0xfeeefeeeになるね
画像ﾘﾝｸ[jpg]:i.imgur.com
380(1): 2019/09/19(木)22:12 ID:1bu8PAPD(1) AAS
>>379
環境は？
十数バイトをdeleteしただけでHeapFreeを呼ぶのも考えづらいし、そもそもこっちでも>>376と同じくHeapFreeで0xfeeefeeeが入ることもなかった
381: 2019/09/19(木)22:36 ID:2Kmv27QM(1) AAS
vs2003とかそのあたりかなこれ
382: 2019/09/20(金)00:25 ID:n3bycm/n(1) AAS
Win10 Pro(32bit)でHeapFreeやってみた
VS2017(Community Edition)は0xfeeefeeeにならなかったが、
VC2010(Express Edition)でやってみたら0xfeeefeeeになったわ(確保していた領域の先頭8バイトほどに0xfeeefeeeじゃない値が入っていたが)
面倒だからオプションとか生成されたバイナリとか詳しく比較してない
383: 2019/09/20(金)09:31 ID:DNSz8VRz(1) AAS
>>380
VC++2010Expressだよ
画像こっちの方がよかったね
画像ﾘﾝｸ[jpg]:i.imgur.com
384(1): 2019/09/28(土)11:23 ID:2Q8qxITa(1) AAS
メッセージ処理の
case（msg）
ってなんで
case（msg.message）
じゃないの？
構造体直接評価できるの？
385: 2019/09/28(土)11:29 ID:2Q7OqYnQ(1) AAS
どこかのサイト？
386: 2019/09/28(土)11:46 ID:QstsG7m2(1/2) AAS
メッセージは構造体じゃなくて UINT やろ
387(1): 2019/09/28(土)14:28 ID:hWveUl7z(1) AAS
>>384
多分サンプルの読み方を勘違いしている
GetMessage関数なんかで使われるlpMsgとかはMSG構造体なので中でメッセージIDを
確認したいならば「msg.message」を見ることになる
メッセージIDのハンドリング行うサンプルなんかで普通に使われてるWndProc関数の
uMsgはUNIT型の「msg.message」が実体なのでcaseでそのままハンドリングできる
でないか？
388: 2019/09/28(土)16:13 ID:91yg28/R(1) AAS
caseにカッコつけんな
389(1): 2019/09/28(土)17:54 ID:zcWtf1aP(1) AAS
本来ライブラリに任せるべきところをかなりネイティブなwinsockプログラミングをしています。
TCP通信にて最大セグメントを超えてwinsock2.sendを行った場合はどうなってしまうのでしょうか？
エラーとなるためそこも自前で実装する必要があるのか、それともwinsockが勝手に分割を行ってくれるのか、はたまたネットワークアダプタやルーターなどのデバイスが勝手にやってくれるのか、どういう挙動となるのかご伝授お願いします
390: 2019/09/28(土)20:46 ID:QstsG7m2(2/2) AAS
ソケット通信てそんなところ気にしなきゃいけなかったっけ？
アップロード・ダウンロードルーチン組んだけど記憶にない
391: 2019/09/28(土)21:19 ID:qwUCk4Gy(1) AAS
winsock2に限ればエラーが返るんじゃないか？
質問するよりもmasdn見たほうが確実だろ
392(2): 2019/09/28(土)21:42 ID:zNn3MVf2(1) AAS
sizeof演算子に括弧つける派です？
393(1): 2019/09/28(土)22:22 ID:ZZfYVsnP(1/2) AAS
UDPだと知らん間に分割された挙句
場合によっては断片が届く順番まで変わるからな
394: 2019/09/28(土)22:24 ID:ZZfYVsnP(2/2) AAS
sizeofに括弧付ける
マクロの引数は使用時に必ず括弧付ける
395: 2019/09/29(日)08:10 ID:qdFsd7WD(1/2) AAS
>>393
> 場合によっては断片が届く順番まで変わるからな
むしろTCPが頑張って順序を元通りに入れ替えてるんだが…
396: 2019/09/29(日)08:12 ID:qdFsd7WD(2/2) AAS
>>392
不要なカッコは付けない派
例外は演算子の優先順位がわかりにくい時に付けるぐらい
理由は間違っててもコンパイルエラーにならないから
397: 2019/09/29(日)08:26 ID:MP9GBJ11(1/8) AAS
>>392
俺も無駄な括弧はつけないな
わざわざつける理由がない
単項演算子の優先順位を知らんアホが仲間にいない
398: 2019/09/29(日)09:39 ID:xMtED3Cu(1) AAS
どこから「単項」演算子の話が…
399: 2019/09/29(日)10:26 ID:MP9GBJ11(2/8) AAS
そのアホがいた・・・驚愕
今 sizeof の話をしているんだが
脈絡が読めないとはな
400(1): 2019/09/29(日)10:29 ID:JKK19nEu(1) AAS
こういう奴が書くソースは総じて読みにくいｗ
401: 2019/09/29(日)10:31 ID:9b9emf+N(1) AAS
付ける派
if(...) switch(...)なのにsizeof(...)じゃないのはなんとなく嫌
402: 2019/09/29(日)11:39 ID:98/tCU9d(1) AAS
どこがAPIの話だ馬鹿は京急に突っ込んで死ね
403(3): 2019/09/29(日)11:53 ID:3s0zt66k(1/2) AAS
hoge = malloc(length * sizeof struct hage *);
hoge = malloc(sizeof struct hage * * length);
hoge = malloc(*length * sizeof struct hage *);
hoge = malloc(sizeof struct hage * * *length);
hoge = malloc(*length * sizeof struct hage **);
hoge = malloc(sizeof struct hage ** * *length);
()付けないとどんどんわかりにくくなっていく
404: 2019/09/29(日)13:23 ID:eQVILPNx(1) AAS
sizeof(型)は()必要だよ
405: 2019/09/29(日)13:34 ID:cKDPFQQS(1) AAS
いらんよ
406(1): 2019/09/29(日)13:50 ID:6WuqtMyk(1/3) AAS
Win32API以外の話は不要
407: 2019/09/29(日)13:54 ID:MP9GBJ11(3/8) AAS
>>400
おまえみたいのに読んでもらう必要が皆無
408: 2019/09/29(日)13:59 ID:MP9GBJ11(4/8) AAS
単項演算子とそうでないものの区別がつかないアホが
return にも括弧したがるんだろうな
# K&R 1st世代の人はともかく
409: 2019/09/29(日)14:05 ID:6WuqtMyk(2/3) AAS
書いてから思ったが、排他の否定な書き方が好きじゃない>>406
読みにくい
肯定した書き方だけに統一したい
そういう意味では、好きじゃないという書き方もダメか
嫌いと書くべきか
ということで、
Win32APIの話をしろ
おやすみ
sizeofは計算式絡むことがほとんどなのと、明示的にした方が分かりやすく
馬鹿らしいミスの回避のためにも付けといて損はない
410: 2019/09/29(日)15:27 ID:MP9GBJ11(5/8) AAS
自分らしいミスか、わかりますｗ
411(1): 2019/09/29(日)15:43 ID:Mg/ytEjl(1/2) AAS
>>403
この例からしても括弧つけた方が見やすいが、ID:MP9GBJ11は見やすさ全否定なの？
俺様はインデントもスペースも改行も無くても、優先順位・スコープ範囲が分かってるから無問題って理屈だよな
412: 2019/09/29(日)15:50 ID:qbYXpMyS(1/2) AAS
typeidもsizeofも関数じゃなくて演算子なんだけど、typeidは括弧が必須。
413: 2019/09/29(日)16:01 ID:EcHpn11g(1) AAS
>>389
TCPのMSSは相手との関係で決まるので何バイト送り込んでもエラーには
ならないと思うけど
TCPとしては送れたデータ量をSeq番号で管理していてセグメントの分割は
ドライバの仕事なのでアプリケーションレベルでは意識する必要なかったと
思うけど
UDPとかIP直みたいなデータグラムの場合には「WSAEMSGSIZE」が返って
くるみたいだけどTCPは平気なんじゃないかな(転送データの保障がある
わけではない)
414: 2019/09/29(日)17:35 ID:3s0zt66k(2/2) AAS
さすがに return にまで () 付けてるのはうざいわ
415(1): 2019/09/29(日)17:44 ID:MP9GBJ11(6/8) AAS
>>411
仲間に書かれても文句は言わねえな
見た目の問題じゃなく、やろうとしている内容がセンスに欠けるときなら
これ例えばこんな手もあるよなと議論に誘ったりはするし
iocccみたいな実験をTPOを間違えてやる大馬鹿野郎がいたら喧嘩売る
実例として/*/野郎は口汚く罵ってやった
416: 2019/09/29(日)17:51 ID:dmuVBgYo(1) AAS
（）なんてあってもなくても分かりやすけりゃいいんだよ
逆に>>403なんて（）あってもなくても読みにくい。俺はこんなの絶対書かないな
417: 2019/09/29(日)18:02 ID:bLCqrou7(1) AAS
sizeof には、極力変数名側を与えるようにして型名は避けるようにしてるけど
WinAPI とは遠い話だな
418: 2019/09/29(日)18:08 ID:MP9GBJ11(7/8) AAS
もうダメ、我慢できないから言っちまおう
>>403は必要な()とそうでないのが解ってねえ
アホｗバカｗｗｗ
419: 2019/09/29(日)18:09 ID:XoUEO8Fx(1) AAS
return (a);
とは書かないけど、
return (a+1);
のときは括弧を付けなくなる
420(1): 2019/09/29(日)18:44 ID:qbYXpMyS(2/2) AAS
GCCではtemplate関数の記述する際に、ある文字列が型であることをコンパイラに教えるtypenameキーワードが必要なので、sizeof に括弧がないと読みづらくなる傾向はある。
421: 2019/09/29(日)21:35 ID:MP9GBJ11(8/8) AAS
>>420
バーカｗｗｗｗｗｗｗｗｗｗ
typenameが必要か否かは規格17.7で明確化されている
422(1): 2019/09/29(日)22:11 ID:Mg/ytEjl(2/2) AAS
>>415
規約や仕様の話じゃなくて見た目の話してるんだから、それを分かっててセンスがどうのこうのって言い出すのなら
この話の流れで草を生やしながら馬鹿まき散らすのは、マジでセンスないねって話になるよ
423: 2019/09/29(日)22:29 ID:6WuqtMyk(3/3) AAS
おはようさん
スレタイ読めない奴は総じてセンスも才能もないってことですよ
424: 2019/09/29(日)22:52 ID:Qb/y7uSu(1) AAS
>>387
ありがとうございました
425: 2019/09/30(月)08:14 ID:069AXC1X(1) AAS
>>422
やろうとしている内容がセンスに欠けているときって言ってるのに規格がどうたらとか、いいからまず涙拭けよw
426: 2019/09/30(月)08:23 ID:h3H1G0XJ(1) AAS
もう少しwindowsに関係した話をだな
427: 2019/09/30(月)09:28 ID:5PqXiw6I(1) AAS
ガイジの出身地方ではWin32APIの範囲なんだろ
428: 2019/09/30(月)12:38 ID:vkIGDak2(1) AAS
Win32APIがsizeof()推奨なのは
hoge * で済むものをわざわざ
typedef hoge *LPHOGE;
とかやっちゃって
sizeof LPHOGE
とかやって
不都合出て来るからだろ
429: 2019/10/01(火)20:49 ID:D6lr/hhZ(1) AAS
Win32 APIはバージョン差を吸収するのにパラメータ構造体にその大きさをセットするので
わりかし sizeof の頻度は高いかもな
430(1): 2019/10/01(火)21:01 ID:OgNbwofS(1) AAS
流れを読まず適当にレスすると
win32apiプログラミングにおけるapiの仕様やsizeofの使用頻度を考えたら括弧付きが自然なのは周知の事実なんだから
それにセンスが何ちゃらと難癖付けてるのはwin32apiプログラミングしてないアホでしょ
こんなん出ました
431: 2019/10/01(火)22:45 ID:WzUe48WU(1) AAS
カッコつけてんじゃねーよ的なやつな
432: 2019/10/01(火)22:51 ID:93GMDhBd(1) AAS
チコちゃんもといカコちゃんみたいな
433: 2019/10/02(水)06:50 ID:c9vI97O0(1) AAS
> win32apiプログラミングにおけるapiの仕様やsizeofの使用頻度を考えたら括弧付きが自然なのは周知の事実なんだから
理由もメチャクチャだし周知とかアホすぎる
> それにセンスが何ちゃらと難癖付けてるのはwin32apiプログラミングしてないアホでしょ
>>430出ましたw
434: 2019/10/02(水)10:31 ID:y1aZWk4e(1) AAS
スレタイ読まないカコちゃんまた来たの？頭弱いね
435: 2019/10/02(水)11:02 ID:I2VMZsV4(1) AAS
sizeofに括弧つけるかどうかなんて
正直どうでも良くね？
436: 2019/10/02(水)11:33 ID:Jzurp0++(1) AAS
構造体にサイズ入れることが一番多いからあんまつけないな
437: 2019/10/02(水)13:04 ID:55+aQRnY(1) AAS
64bit化してからHOGE_PTRが増えてさらに混乱
438: 2019/10/07(月)18:52 ID:gF1mLPnp(1) AAS
sizeof付けるの嫌ならラッパー作ってそっちで呼び出せよ
win32APIの仕様がそーなるんだからしかたねーじゃん。手続き通りに記述するしかない。
439: 2019/10/07(月)20:15 ID:WFXsDvHg(1/2) AAS
perlでWin32APIを使うライブラリWin32::APIを使ってると、
32bitと64bitで異なる構造体のアラインメントを正しく解釈してくれないので、アセンブラ並みに低レベルな記述が必要になることがある。
440(1): 2019/10/07(月)21:01 ID:Byy1mx9U(1) AAS
cからperl呼ぶのも腐ってるな
441: 2019/10/07(月)22:23 ID:WFXsDvHg(2/2) AAS
>>440
世の中には発酵食品が沢山ある。
発酵 腐敗 熟成 の違いを見極めるのは難しい。
442(1): ◆QZaw55cn4c 2019/10/09(水)21:21 ID:ggd9iNPq(1/4) AAS
質問です。
SetFilePointer()
外部ﾘﾝｸ:docs.microsoft.com
を FILE_END で使ったことのある方はおられますか？
第3引数 PLONG lpDistanceToMoveHigh を 0 （そして第 2 引数 LONG lDistanceToMove も 0 ）で使うと、FILE_END であっても当のファイルが 4GB 以上の場合にはポインタがファイルの最後に設定されない現象があるようです
この場合ダミー変数（毎回 0 を投入している）を設けて lpDistanceToMoveHigh にそのアドレスを設定すると FILE_END がその本来の意味を示すようにみえます。
推量形で記述しているのは、私の環境（mingw64-gcc）ではコンパイラのオプティマイザが過剰に効いている可能性があり -O0 でコンパイルしてはじめて、ある程度この現象が確認できたという事情のためです。
これは一般的な話なのでしょうか？
443(1): ◆QZaw55cn4c 2019/10/09(水)21:24 ID:ggd9iNPq(2/4) AAS
>>442
ソースを晒します
外部ﾘﾝｸ:ideone.com
444(2): 2019/10/09(水)21:49 ID:75Pp/Qaq(1) AAS
longの場所になぜintを使う
445(2): ◆QZaw55cn4c 2019/10/09(水)22:06 ID:ggd9iNPq(3/4) AAS
>>444
printf("sizeof(int):%d, sizeof(LONG):%d\n", sizeof(int), sizeof(LONG));
$ ./a.exe
sizeof(int):4, sizeof(LONG):4
446(1): 2019/10/09(水)22:12 ID:wmrCsqX1(1) AAS
lpDistanceToMoveHighがNULLの時のFILE_ENDは単純にファイルサイズも下位32bitだけ見て処理してそう
でかいファイル扱うなら素直にSetFilePointerEx使った方がよさげ
447(1): ◆QZaw55cn4c 2019/10/09(水)22:39 ID:ggd9iNPq(4/4) AAS
>>446
*Ex には気がつきませんでした
昔書いたものをみると
s1 = GetFileSize(f, &s2);
SetFilePointer(f, s1, (PLONG)&s2, FILE_BEGIN);
WriteFile(f, p, strlen(p), &n, 0);
ってやっていましたから、どうも、昔も同じところで嵌ったらしく、お茶を濁す方法まで昔と同じのまま、しかもその記憶が今はない…
もうなにもかも忘れてしまった…
コメントありがとうございました
上下前次1-新書関写板覧索設栞歴
あと 555 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s