回答編集履歴

3

scanf() 対策を追加

2020/03/01 22:59

投稿

rubato6809
rubato6809

スコア1382

test CHANGED
@@ -569,3 +569,33 @@
569
569
  ・・・と、これだけでも、他の人が使えるコード品質になるには道のり長そうですね。
570
570
 
571
571
  Enjoy !
572
+
573
+
574
+
575
+ > scanfを入れているのは、表示を確認するために一時停止をしたいから
576
+
577
+
578
+
579
+ そのためにグローバル変数に読み込むのは本末転倒・言語道断。その後 fwrite() はどうなるか考えよ。
580
+
581
+ scanf() で停止するなら <stdio.h> の入力関数 fgets() 等でも停まります。getchar(); とだけ書いたこともあるけど、普通は小さな関数を作って、停めたい所で呼ぶでしょう。
582
+
583
+ ```C
584
+
585
+ // extern int n; ← NG! 現状、こうなっている
586
+
587
+ void wait4keyinput(void)
588
+
589
+ {
590
+
591
+ int n; // 読み込む変数はローカルに取るべし
592
+
593
+ printf(" (hit return) "); // 何か表示させたほうが良いだろう
594
+
595
+ fflush(stdout); // just in case
596
+
597
+ scanf("%d", &n); // fgets(line, LINESIZE, stdin); という手も
598
+
599
+ }
600
+
601
+ ```

2

コードレビュー、さらに追加

2020/03/01 22:59

投稿

rubato6809
rubato6809

スコア1382

test CHANGED
@@ -401,3 +401,171 @@
401
401
  そもそも引数の f は、構造体そのものを引数にするのではなく、元の構造体へのポインタ(アドレス)だけ受け取れば十分なのではないか。構造体を引数にすると、実引数から仮引数へコピーが毎回発生するので効率悪い。
402
402
 
403
403
  (もう寝るw)
404
+
405
+
406
+
407
+ ---
408
+
409
+ さらに追加します。
410
+
411
+
412
+
413
+ - 実際、不要なローカル変数が山のよう・・・
414
+
415
+
416
+
417
+ - 関数の最後にあるべき return 文が無く、関数の最後で目的の値を返さない経路がある。既に、上で int deg(vec a) 関数を指摘したが、他にもあった。コード品質の低さを示すもの。
418
+
419
+
420
+
421
+ unsigned short oinv(unsigned short a) // BUG !!!
422
+
423
+ unsigned char chk(OP f)
424
+
425
+ int isqrt(unsigned short u)
426
+
427
+ OP osqrt(OP f, OP w) --- 長大な関数
428
+
429
+
430
+
431
+ - 信用を失う滅茶苦茶な関数w
432
+
433
+ ```C
434
+
435
+ OP ToHorner(OP f)
436
+
437
+ {
438
+
439
+ vec v = o2v(f); // この計算は何?
440
+
441
+ OP h;
442
+
443
+ return h; // 不定値を返す OMG
444
+
445
+ }
446
+
447
+ ```
448
+
449
+
450
+
451
+ - 変数に代入するが使わない。何をするつもりか意図が不明な処理が多数見つかる。
452
+
453
+
454
+
455
+ ```C
456
+
457
+ // 計算結果を使わない例1
458
+
459
+ int main(void) // argc, argv を使わない
460
+
461
+ {
462
+
463
+ unsigned short mm[T]; // mm[t] = {0} 初期化不要
464
+
465
+ // 途中省略
466
+
467
+ for (i = 0; i < T; i++) {
468
+
469
+ mm[i] = r.t[i].a; // mm[i] に代入するも、使わない
470
+
471
+
472
+
473
+ // 計算結果を使わない例2
474
+
475
+ OP ogcd(OP f, OP g) // ユークリッドの互除法?
476
+
477
+ {
478
+
479
+ OP h, ww; // 初期化不要
480
+
481
+
482
+
483
+ for (int i = 0; i < T; i++) {
484
+
485
+ h = omod(f, g);
486
+
487
+ ww = odiv(f, g); // この除算は不要
488
+
489
+ f = g;
490
+
491
+ g = h;
492
+
493
+ }
494
+
495
+ // 一方、xgcd() は除算した結果 ww を使う。そこをコピペしたか?
496
+
497
+ ```
498
+
499
+
500
+
501
+ lu.c を拝見しました。
502
+
503
+ - 一文字のグローバル変数が!言語道断モノですw
504
+
505
+ ```C
506
+
507
+ int i, j, k; // カウンタ !!! OMG !!!
508
+
509
+ int n = F; // 配列の次数 ??? for fwrite()
510
+
511
+ ```
512
+
513
+ ここをコメントアウトすると、これらに頼っているコードが判明します。
514
+
515
+ この小文字変数 k に頼るコードが det() 関数に見つかります。
516
+
517
+ ```C
518
+
519
+ void det(unsigned short g[])
520
+
521
+ {
522
+
523
+ // 省略
524
+
525
+ k = cc[K];
526
+
527
+ // 途中省略
528
+
529
+ cc[K] = k;
530
+
531
+ ```
532
+
533
+ この大文字「K」は #define K 128*2 という定数マクロです。大文字・小文字のK, kを一緒に使うのは、いかがなものかと(乱視が悪化してきた私は)思う。
534
+
535
+
536
+
537
+ i, j, k は、頼っている関数にローカル変数を追加すれば削除できます。
538
+
539
+ 問題は n です。n の主目的は fwrite(dd, 1, n, fq); の引数とみられますが、他の箇所から n の値を変更可能です。たとえば oplib.c に scanf("%d", &n); が何箇所かあり、(意図通りかどうかは不明だが)キー入力した値がこの n に読み込まれるらしい。グローバル変数に対する典型的な戒めを変数「n」に見出すことができます。
540
+
541
+ しかも「n」という変数名は、関数内のローカル変数にもあるうえに、oterm 構造体のメンバ変数でもある。カオスです。
542
+
543
+
544
+
545
+ グローバル変数、マクロ名、寿命の長い変数、アルゴリズム的・意味的に重要な変数などはもっと長い変数名にしたほうが良いでしょう。ひとつの目安は grep コマンドで、それぞれの変数が登場する箇所を特定できること、でどうですか。
546
+
547
+
548
+
549
+ - chash.cpp - 拡張子 cpp は C++ ソースを意味するが、実際は C 。
550
+
551
+
552
+
553
+ ```C
554
+
555
+ void SHA512_transform(unsigned long long H[], unsigned long long W[])
556
+
557
+ {
558
+
559
+ static const unsigned long long K[80] = {
560
+
561
+ 0x428a2f98d728ae22ULL, 0x7137449123ef65cdULL,
562
+
563
+ ```
564
+
565
+ K[] という配列名は #define K 128*2 と被ります。コードの可読性・保守性の観点から、両方の「K」という名前をそれぞれ変更したほうが良いと思います。
566
+
567
+
568
+
569
+ ・・・と、これだけでも、他の人が使えるコード品質になるには道のり長そうですね。
570
+
571
+ Enjoy !

1

回答を修正、コードレビューを追加

2020/02/29 15:13

投稿

rubato6809
rubato6809

スコア1382

test CHANGED
@@ -1,10 +1,10 @@
1
- 多数のOP構造体変数がスタック領域に取られることから、**スタックオーバーフローが起こった**はないかと見ています。
1
+ 多数のOP構造体変数がスタック領域に取られることから、**スタックオーバーフローが起こった**ようです。
2
-
3
-
4
-
2
+
3
+
4
+
5
- OP型構造体変数は3072バイトのサイズはないかと。それがローカル変数としてスタック上にいくつもとられ、pattarson(), xgdb() 関数の引数にもなっています。他にもサイズの大きな変数が見つかります。スタックオーバーフローを起こしているとすれば、コード全体で変数の設計を考えなおす必要があると思います。
5
+ OP型構造体変数のサイズは3072バイトで。それがローカル変数としてスタック上にいくつもとられ、pattarson(), xgdb() 関数の引数にもなっています。他にもサイズの大きな変数が見つかります。コード全体で変数の設計を考えなおす必要があます。
6
-
6
+
7
- なお、-O2 最適化した場合は、ローカル変数の使用量を減らすような最適化がおこなわれるはないかと想像しています。
7
+ -O2 最適化した場合は、ローカル変数の使用量を減らす最適化がおこなわれるようです。
8
8
 
9
9
 
10
10
 
@@ -147,3 +147,257 @@
147
147
 
148
148
 
149
149
  コードレビューする側としてコメントしたいことはありますが、取り急ぎ問題点と思われる点を回答します。お気づきのように、既にコードに手を入れて、少しづつ私のスタイルに変更しつつあります。
150
+
151
+
152
+
153
+ ---
154
+
155
+ #スタックオーバーフローによってSegmentation Faultが起こった事は確実
156
+
157
+
158
+
159
+ > 使ってないOP構造体がたくさんありすぎてメモリが溢れた
160
+
161
+
162
+
163
+ その結果、
164
+
165
+ > -O2 最適化した場合は、ローカル変数の使用量を減らす最適化がおこなわれる
166
+
167
+
168
+
169
+ スタックオーバーフロー直前のスタックトップ付近のアドレスと、main() が動作開始した時点のスタックポインタ(付近)の差をとれば、どれだけスタック領域を消費したかがわかります。手元で調べたところ、約7.8MB消費したことがわかりました。xgcd() もスタックに巨大なローカル変数(v[K*2], u[K*2]等)を取りますので、それらを初期化しようとしたところで落ちたのでしょう。
170
+
171
+ 一方、-O2オプションでコンパイルすると未使用な変数は削除され、スタック領域の消費量が減り、3.8MB程度に半減したことがわかりました。
172
+
173
+
174
+
175
+ > 16Gもメモリを積んでいるので暴走しないはず
176
+
177
+
178
+
179
+ 各プロセスは実装メモリを独り占めすることはできません。OS(Linux, Windows等)はメモリ資源を管理しており、プロセスには実装メモリの一部分しか与えないからです。
180
+
181
+ [実行時スタックサイズ変更 on Linux](https://stakizawa.hatenablog.com/entry/20061017/t1)を見ると、デフォルトは8192であり、これは8MBがプロセスに与えられることを意味します。約7.8MB消費した時点でスタックは溢れる寸前だったわけです。このページに倣って、16MBのメモリを与えると最適化しないプログラムも動作を続けることができました。即ち、スタック領域が足りなかったことは確実です。
182
+
183
+ ```bash
184
+
185
+ $ ulimit -s 16384 <<= 16MB に拡張する
186
+
187
+ $ ./a.out <<= 動作できる
188
+
189
+ ```
190
+
191
+ ---
192
+
193
+ コードレビューしてみます。
194
+
195
+ - 不要な変数は削除しましょう。pattarson() 関数の中をざっと見ただけですが、
196
+
197
+ ```
198
+
199
+ unsigned short m[K],mm[T]={0},dd[K*D]={0}; // <<= すべて不要
200
+
201
+ OP h={0},r={0},aa[K]={0},tt={0},ff={0}; // aa[k] が不要
202
+
203
+ ```
204
+
205
+ OP aa[K]; だけで 786KB (== 3072 * 256)を消費します。こうした未使用の変数を削除するには**全ての警告(warning)を出させる**オプション -Wallを指定するとよいです。
206
+
207
+ $ cc oplib.c -Wall
208
+
209
+
210
+
211
+ - 不要な変数を、各関数に同じようにとっているかのようにも見えます。そこから、変数のスコープを理解していないのではないか、各関数の役割を整理しないままコーディングしているのではないか、といったことを疑います。
212
+
213
+ - コードが記述されたファイルをインクルードするのはイリーガル。インクルードするのはヘッダファイルにするのが普通。ヘッダファイルには定義を書き、コードは書かない。
214
+
215
+ ```
216
+
217
+ #include "chash.cpp" // インクルードしてはいけない。分割コンパイルせよ
218
+
219
+ #include "lu.c"
220
+
221
+ ```
222
+
223
+ 一番簡単な分割コンパイルのやり方は次(他にも修正が必要になりそうなので私は試してない)。
224
+
225
+ $ cc oplib.c chash.cpp lu.c
226
+
227
+
228
+
229
+ - 計算式で定義する定数マクロはカッコで囲むのが安全。数字をカッコで囲む人もいる。
230
+
231
+ ```
232
+
233
+ #define K (128*2) // こうしたマクロはカッコで守ろう
234
+
235
+ #define DEG (3*K)
236
+
237
+ #define T (K/2)
238
+
239
+ #define E (13)
240
+
241
+ #define D 6688 // こういう値の意味・根拠は?
242
+
243
+ ```
244
+
245
+ - K, T, E, D, c[2 * K + 1], g[K + 1] ・・・このように文字数の少ない識別子が大手を振って使われるのは、よくありません。スコープが狭い、或いは寿命が短い変数であれば構いませんけど。
246
+
247
+ - 構造体のメンバ名が短いのは、構わないけど、何か説明のコメントが欲しくなります。
248
+
249
+ ```
250
+
251
+ typedef struct {
252
+
253
+ unsigned short n; // 何かコメントを書こう
254
+
255
+ unsigned short a;
256
+
257
+ } oterm;
258
+
259
+ ```
260
+
261
+ - deg()関数はreturn値が不定となる可能性あり。-Wallは警告するかもしれない。
262
+
263
+ ```
264
+
265
+ int deg(vec a)
266
+
267
+ {
268
+
269
+ // 省略
270
+
271
+ if (n > 0)
272
+
273
+ return n;
274
+
275
+
276
+
277
+ // 警告!!!nが0なら戻り値は不定?
278
+
279
+ }
280
+
281
+ ```
282
+
283
+ if (n > 0) という条件判定は不要で、単に return n; すれば良いのではないか。
284
+
285
+
286
+
287
+ - 構造体を返す関数に注意。o2v(), v2o(), init_op()等は、ポインタを受け取って、そこに結果を書き込んだほうが効率が良いのだけどなあ・・・
288
+
289
+
290
+
291
+ - OP oadd(OP f, OP g) も、上記のようにポインタを受け取りそこに結果を書き込むこともできるが、今の仕様のままでもツッコミどころがいくつか。初期化が不要な変数だってある、初期化だけでも時間はかかる。
292
+
293
+ ```
294
+
295
+ OP oadd(OP f, OP g)
296
+
297
+ {
298
+
299
+ #ifdef ORIGIN
300
+
301
+ vec a = {0}, b = {0}, c = {0}; // a, b は初期化不要
302
+
303
+ #else
304
+
305
+ vec a, b, c = {0}; // c は0クリアしたほうが安全か
306
+
307
+ #endif
308
+
309
+ int i, k;
310
+
311
+ OP h = {0}; // 不要。下の return を見よ
312
+
313
+
314
+
315
+ a = o2v(f); // ここで a, b に値が代入される。0クリアする必要無し
316
+
317
+ b = o2v(g);
318
+
319
+
320
+
321
+ #ifdef ORIGIN // 元のコード
322
+
323
+ // 実行時、deg() を3回呼び出すが
324
+
325
+ if(deg(a) >= deg(b)){
326
+
327
+ k=deg(a)+1;
328
+
329
+ }else{
330
+
331
+ k=deg(b)+1;
332
+
333
+ }
334
+
335
+ #else          // 改良コード
336
+
337
+ int ka = deg(a); // 一時変数に取れば、呼出しは2回で済む
338
+
339
+ int kb = deg(b);
340
+
341
+ if (ka >= kb) {
342
+
343
+ k = ka + 1;
344
+
345
+ } else {
346
+
347
+ k = kb + 1;
348
+
349
+ }
350
+
351
+ #endif
352
+
353
+ // c を0で初期化しておく必要はあるか? 不明
354
+
355
+ for (i = 0; i < k; i++)
356
+
357
+ c.x[i] = a.x[i] ^ b.x[i]; // ここで c は x[k-1] まで決定する
358
+
359
+
360
+
361
+ #ifdef ORIGIN
362
+
363
+ h = v2o(c);
364
+
365
+ return h;
366
+
367
+ #else
368
+
369
+ return v2o(c); // 元の2行は1行で書けるので h は不要
370
+
371
+ #endif
372
+
373
+ }
374
+
375
+ ```
376
+
377
+ - ループの中で構造体変数 f の値は変化しないので、terms(f) は一回計算するだけで良い。
378
+
379
+ ```
380
+
381
+ int odeg(OP f)
382
+
383
+ {
384
+
385
+ int i, j = 0, k;
386
+
387
+ #ifdef ORIGIN
388
+
389
+ for (i = 0; i < terms(f) + 1; i++) { // terms(f) を毎回計算するの?
390
+
391
+ #else
392
+
393
+ k = terms(f) + 1; // 計算は一回だけ
394
+
395
+ for (i = 0; i < k; i++) {
396
+
397
+ #endif
398
+
399
+ ```
400
+
401
+ そもそも引数の f は、構造体そのものを引数にするのではなく、元の構造体へのポインタ(アドレス)だけ受け取れば十分なのではないか。構造体を引数にすると、実引数から仮引数へコピーが毎回発生するので効率悪い。
402
+
403
+ (もう寝るw)