C言語なら俺に聞け 145

2018/02/19(月) 22:13:58.98

C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

前
C言語なら俺に聞け 144
https://mevius.5ch.net/test/read.cgi/tech/1514025223/

次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2018/03/05(月) 22:18:31.83

１万行なんて、きちんと設計してないんじゃね？

2018/03/05(月) 22:28:13.08

sizeof(void)って未定義？
未定義ならそのポインタの加算幅も未定義だな。
void* p = (((void*)(&i))++);

2018/03/05(月) 23:16:20.23

キミは正しい

2018/03/06(火) 03:28:05.03

本当は void * に対しては足すことも引くこともできない。

2018/03/06(火) 06:45:37.01

今ならuintptr_tにキャストして足し算引き算した後でvoid*に戻すのかな。
uintptr_t以前はchar*へのキャストだったかも知れんけど。

しかし実際のところvoid*に対してポインタを進めたり戻したりしたいって、
どういう場面で必要になるんじゃろうか?

2018/03/06(火) 09:29:43.76

char *でいいじゃん
構造がわからないものはバイト列って認識でしょ？

2018/03/06(火) 10:18:02.26

分からない物を適当に扱うって、すごいな

2018/03/06(火) 12:31:29.65

しかも符号まであると決めつけてるな

2018/03/06(火) 12:40:00.86

GCCとかchar*と同じ挙動じゃなかったっけ？

2018/03/06(火) 12:50:23.18

gccはね。

2018/03/06(火) 12:54:06.75

そういやポインタ演算と言うと8086用のCコンパイラはfarとか拡張キーワード作ったりして面倒だったな。TurboCだったか。
ああいうなんとも言えないCPUコンパイラだと特殊な決まりがあったりするから要注意だ。

まあ、二度とあんなの市場に出ないような気はするけどな。

2018/03/06(火) 12:54:48.33

用のが抜けた。CPU用の、な。

2018/03/06(火) 12:56:39.10

ハーバードアーキテクチャだとdmとかpm修飾なんてのも

2018/03/06(火) 13:31:13.79

farはTurbo Cに限ったことじゃない
8086用である限り必要になる

2018/03/06(火) 14:52:33.73

tinyモデルでも使えるfar最強

◆QZaw55cn4c (ﾜｯﾁｮｲ df60-k3ZN) · 2018/03/06(火) 15:01:22.33

>>279
でもコード64KBの制限はどうしようもない

2018/03/06(火) 16:57:53.89

64KBしかいらないときに使うのがtiny
tiny使いながら64KBじゃきついとか発想が逆
だったら端っからlarge使えつーの

2018/03/06(火) 17:18:40.34

>>281
それは根本的な間違い
誤解産むからやめれ

2018/03/06(火) 21:11:42.80

>>272
charか符号付きかどうかは処理系とかによる
なので決めつけてるのはお前ってオチ

2018/03/06(火) 21:46:56.01

整数の差分じゃなくてポインタの差分じゃろ？

2018/03/06(火) 21:52:27.71

char は、符号付き・符号なしの、どちらか分からないから使うな！

エラーに、-1 を使っていたら、0～255 しか表現できない事もある

2018/03/06(火) 21:58:50.50

>>285
9bitなの？(T_T)

2018/03/06(火) 22:17:46.38

例外を範囲外の値で判定する様なインターフェースが悪い。
はっきり戻り値は動作結果、値は出力用の引数に入れる。
みたいな設計にすべき。
ちな、C#みたいに戻り値を構造体にするって手もあるぞ。

2018/03/06(火) 23:01:01.51

素人が、char型の-1 を、エラー値に使っていると、
OS・コンパイラが変わって、その環境では、char型が0～255 になってる

char型は、符号付き・符号なしの、どちらか分からない

◆QZaw55cn4c (ﾜｯﾁｮｲ df60-k3ZN) · 2018/03/06(火) 23:07:35.07

>>288
言語内の話と環境（シェルやOS)の話を混同してはならない

2018/03/06(火) 23:46:04.03

signed char って書けば?

2018/03/07(水) 02:24:03.38

>>288
charの使い方が間違っていることが問題なのであって、charを使うこと自体が悪いのではない。

2018/03/07(水) 02:45:29.86

はいー。
1バイト整数を使いたかったら、stdintを使いましょう。
int8_tは内部がcharかもしれないけど便宜上charではありません。
ハイ、復唱。int8_tはcharではありません。
ちなみにC++でバイト表現専用のstd::byteが入りました。すごく使いにくいけど。

2018/03/07(水) 10:31:28.26

>>282
どこか間違っているか？

2018/03/07(水) 12:28:33.48

gets_sのsは何の略か教えてください。

2018/03/07(水) 12:31:25.66

secure

2018/03/07(水) 12:53:17.89

>>294
Windows用のコンパイラの話？
知らないけど、多分 size の s じゃない？

2018/03/07(水) 12:53:35.53

>>295
あ、それか。

2018/03/07(水) 12:59:49.73

stopper

2018/03/07(水) 13:42:40.79

昔はpc-98DOS用に作ったソフトがハード依存コードが無ければ
DOS/V機やTOWNSでも動くって聞いて驚いた。

2018/03/07(水) 13:49:17.29

safe

2018/03/07(水) 16:58:54.65

N5200 で LSI C-86 試食版を使ってた……ような気がする。昔のことだから記憶が曖昧だ。

2018/03/07(水) 17:13:49.35

vz?

2018/03/07(水) 17:14:24.12

MS-DOSが動作していれば使えるはず

2018/03/07(水) 17:17:05.15

dispelしなきゃ無理じゃね？ｗ

2018/03/07(水) 17:21:00.28

secureじゃねーだろ。
暗号化だってされてねーんだからw
safetyくらいな感じじゃね？

2018/03/07(水) 17:25:48.32

DOSのシステムコール(なんて言うんだっけ？DOSコール？忘れた)だけを呼び出しているプログラムならハードウェアが違っても動く。

しかしMS-DOSはCUIしかサボートしてないのでグラフィックスは使えない。

当時のプログラムはみんな勝手にOS無視してグラフィックスのVRAMに直接アクセスして絵を出していた。
すると当然他の機種に持っていくと意図した通りに動かない。

2018/03/07(水) 17:26:24.22

int21

2018/03/07(水) 17:27:45.62

INT 21H ならファンクションコールだったかの

2018/03/07(水) 17:28:50.29

伝統のCALL ５

2018/03/07(水) 17:29:37.78

DOSCALLS.DLLてのもあったなあｗ

2018/03/07(水) 17:55:21.18

CP/M か
0066 とかもあったっけ

2018/03/07(水) 19:19:15.79

>>296-298, >>300, >>305
お前らがどう思おうとマイクロソフトはセキュリティ強化版って言ってるから

2018/03/07(水) 21:48:34.17

super man

2018/03/08(木) 05:46:05.86

#define a(b) c##b##d
というマクロでcdを出力したいのですが
a()を呼び出すとエラーになります
解決策ありますでしょうか？

2018/03/08(木) 07:45:03.75

>>314 俺のところはエラー出ないみたい。環境によるのかな。
コンパイラのバージョンを示せば詳しい人が現れるかも。

2018/03/08(木) 07:52:57.57

ありがとうございます。
解決しました。

2018/03/08(木) 08:09:34.78

どう解決したか書くのが礼儀ってもんだ。

2018/03/08(木) 08:29:41.94

コンパイラーのエラーが出ないという意見をきいて
試してみたら別のところ―がエラーになっていたということでした。
そして自分が悪質なコンパイラーに騙されていたことに気づきました。

2018/03/08(木) 09:10:26.22

エラーの文章くらい読めよ。

2018/03/08(木) 10:10:36.36

Cのエラーはエラーの発生個所を教えてくれるけど原因個所は教えてくれない

2018/03/08(木) 10:25:51.65

おそらく警告とエラーを混同していると思われ

> warning C4003: マクロ 'a' に指定された実引数の数が少なすぎます。

2018/03/08(木) 17:10:32.81

関数型マクロの使用時、カッコの内側が空の場合に、
「引数が指定されていない」と解釈して警告を出すか、
「1個の引数(内容はヌルストリング)が指定されている」と解釈するか、
そういう問題みたいね。

2018/03/08(木) 23:40:10.76

>>292
>int8_tは内部がcharかもしれないけど便宜上charではありません。

普通はsigned charだな。当たり前。「charかもしれない」なんてこともありえない。

2018/03/09(金) 00:58:31.73

そういう一般仕様から外れるコンパイラの使用を強制させられたことあるの？

2018/03/09(金) 06:39:09.84

cout << typeid(__int8).name(); //char

2018/03/09(金) 10:59:36.49

誰だよCの話題に別言語持ち出してんの。

2018/03/09(金) 12:10:45.59

いやらCね

2018/03/09(金) 12:13:57.64

頭おかC

2018/03/09(金) 16:36:39.04

符号なし64ビット整数を64ビット右シフトすると
０にならないでそのままの時や変な別の値になるときがあるんですけど
コンパイラーのバグですか？

2018/03/09(金) 17:10:28.27

>>329
もしかしてですが、
悪質なコンパイラに騙されているのでは？

2018/03/09(金) 17:10:41.68

http://fast-uploader.com/file/7076138459666/
2つのファイルが無いと再現できなかったのでソースファイルを
アップロードしました
コンパイルしてなぜ０にならないのか教えてください。

2018/03/09(金) 17:11:34.80

>>329
a >> b で、bの値がaの型のビット数「以上」のときは未定義動作、
に該当するから、コンパイラのバグではない。…と思う。

本当は規格の引用をすべきなんだが、どなたか頼む。

2018/03/09(金) 17:12:19.58

コンパイラーは
gcc version 7.3.0 (Rev1, Built by MSYS2 project)
で試しました。
悪質なコンパイラーに騙されているのかもしれませんね。

2018/03/09(金) 17:25:01.13

ファイル１
#include<stdio.h>
#include<stdint.h>
uint64_t f(uint8_t a,uint64_t b){
printf("%llx\n", b>>(64-a));
return b>>64-a;}
void e(uint8_t a){ f(0,0x8318318318318318);}
void g(uint8_t a){ f(a,0x8318318318318318);}
ファイル２
#include<stdint.h>
uint64_t f(uint8_t a,uint64_t b);
void g(uint8_t a);
void e(uint8_t a);
int main(void) {
g(0);
e(0);
return 0;
}
この二つのファイルをコンパイルして実行してみてください。
よろしくお願いします。

2018/03/09(金) 17:27:15.48

その昔、CPUのバグで16bitレジスタを32bitシフトすると0にならないとかいうのなかったっけ

2018/03/09(金) 17:45:47.23

これからは64ビットのシフト使ってるコードは全てバグの温床になるな。

2018/03/09(金) 18:10:27.57

C11の6.5.7の3より。
If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.

**332** (ﾜｯﾁｮｲ fb93-ao9L) · 2018/03/09(金) 20:12:23.00

>>337 フォローありがとう。この部分ですわ。
6.5.7 Bitwise shift operators ビットシフト演算子の項。

もしも右オペランドの値が負、または汎整数拡張後の左オペランドの(ビット)幅より
大きいか等しい場合、振る舞いは未定義である。

と言った感じかな。
promoted left operand の部分が「汎整数拡張後の左オペランド」で
合ってるのか自信ないけど。

2018/03/09(金) 21:17:55.13

64bit 符号なしを、64bit シフトするって、そもそも無意味だろ

元のビットが残っていない。
全部のビットが変わっている！

意味があるのは、63bit まで

**デフォルトの名無しさん** · 2018/03/09(金) 22:22:53.87

>>339
0になってくれれば余計な分岐やら演算やらを省けるかもしれないだろ

2018/03/09(金) 22:57:22.97

0クリアする最適な方法なの？

2018/03/09(金) 23:23:40.83

1010 XOR
1010
----
0000

n は任意のビットで、n XOR n で、全ビット0にできる

**デフォルトの名無しさん** · 2018/03/09(金) 23:25:22.45

>>342
そんなん全ビット読まなきゃいけないじゃん

2018/03/09(金) 23:29:26.36

n and 030 とかで任意ビットのonはわからないか？

2018/03/09(金) 23:47:39.35

＞0クリア
つゼロレジスタ

2018/03/10(土) 00:03:47.54

1 bit づつじわじわシフトするなら何とかなるんだけどな。
https://paiza.io/projects/D9KFwMa77ifp6AOgAaO2PQ

2018/03/10(土) 05:55:47.17

定数リテラルにullって使ってなくてもだいじょうぶなんだっけ？

2018/03/10(土) 12:12:18.84

>>343
xor は少サイクルなのが利点ですね。

2018/03/10(土) 13:08:59.94

アセンブリコードの0にする方法はxorやのう

2018/03/10(土) 13:24:16.81

CPU依存すぎる

2018/03/10(土) 13:47:45.54

Z80時代の爺だろ、放置してやれ

2018/03/10(土) 14:18:47.85

パチンコ屋さん

2018/03/10(土) 15:25:43.76

今じゃ乗除演算さえワンサイクルの時代に何アホな話してんだ？

2018/03/10(土) 16:20:41.72

アセンブラについてはどうしても自分でアセンブリ言語で書かねばならない事態に陥らない限り書くことはないだろうなあ。

◆QZaw55cn4c (ﾜｯﾁｮｲ 8a60-hn8E) · 2018/03/10(土) 16:50:09.76

>>354
そうそう、printf デバッグでは力不足でもう否が応でも gdb に行くのを逃げ回っているのと同じです

2018/03/10(土) 17:18:49.50

gdb は普通に使うなあ。

2018/03/10(土) 17:35:13.89

printfなめたらいかん

2018/03/10(土) 17:41:43.93

割り込みん中でprintf使って暴走してデバッグが出来なかった思い出。

2018/03/10(土) 18:10:52.64

俺はシグナルハンドラの中でログ出力しようとして FILE * 経由で fprintf() 等で出力したら
そのライブラリの中でデッドロックしてハマった。 kill -ABRT で core dump させて gdb
で core ファイルと共に読ませてようやっと停止箇所がわかった。

2018/03/10(土) 20:11:43.97

gdbマスターしてからprintデバッグバカにしてたけど
printデバッグ自動化してからprintデバッグ信者になった
無論レアケースデバッグはgdb使うけどね

2018/03/11(日) 01:20:23.17

printf() をデバッグで使う時はバッファリングを考慮していないとハマる事がある。
それと stdout と stderr と両方に出る可能性がある場合にその順序が食い違う可能性もある。
シグナルハンドラ内やマルチスレッドプログラムで使ってうまく行かない事もある。

その辺を全て考慮するならいいだろうが、しかし、それなら初めからログファイルに出力される
ように作った方が良いような気もする。

2018/03/11(日) 02:00:44.19

printデバッグなら専用モジュール作るべきだな
俺は時刻、関数名、コンテキストIDを付けて
標準出力かファイルにはかせてる

2018/03/11(日) 09:19:44.59

そこまでするならsyslog

2018/03/11(日) 10:20:33.73

>>361
setvbuf忘れなければ済む話だよパパ