読者です 読者をやめる 読者になる 読者になる

テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

(nim report) 整数型はsignedを使うのが基本

Araqが, unsignedを嫌ってるという話を前にしたかも知れない. nimは, unsignedを使いにくく意図的に設計されてて, その意味が全くわからない(Cと同じにしてくれよ)のだが, Araqいわく, 「unsignedはセマンティクスが(ry」とのこと. 結論としては, コンパイラの実装を考えた場合, unsignedを軽視するのが良いらしいのだがピンと来ない.

だけど, 使い勝手でいうと, 整数に関して定義されるarithmetic operationsは, 単なるbit operationsなので, singednessは大して意味がないというのは理解出来る(それに人間に対する表現としてしか意味がない). つまり重要なのはbit-widthのみということになるということも理解出来る. よって, AraqがC世界のu32をint32でusuallyマッピングすると言ってるのも理解出来る. Nimは, この点を強く強調している言語なのだろうが, その理由は理解出来ない.

とりあえず, 盲目的なプラクティスとして, signed型を使う方がnimとの親和性は良いということは言える. なので, nim-fuseについて, lowlevelのインターフェイスについてはそうデザインしようと思う. highlevelについては, これはCの完全なるコピーにしようと思う. ここでオリジナリティを発揮してnimishだとか言っても, あまり意味はないし却ってわかりにくくなる. ただし, posix.nimにある型は積極的に使っていこうと思っている.

10:39:31 akiradeveloper  I know Araq don't like unsigned int. So it's usually recommended to use signed int? If we are interfacing unsigned values in C?
10:40:19    Araq    usually in C "unsigned" doesn't mean much. the C developer thinks it means "natural number" but this is just wrong
10:40:41    Araq    so I usually map it to a signed integer of the same size
10:41:59    Araq    but that's what I do I don't think there is a consensus really
10:44:00    akiradeveloper  You know I am developing fuse binding and once I design the interface to use unsigned a filesystem implementation needs too much casting
10:45:01    akiradeveloper  Really annoys me... So I am considering rewrite them by signed. I don't use windows.nim that's what I picked while researching
10:46:35    *   TEttinger quit (Ping timeout: 264 seconds)
10:48:16    akiradeveloper  inode number is 64bit unsigned for filesystems to have 2^64-1 inodes... This sounds to me not misuse of unsigned value
10:50:02    akiradeveloper  I think it's convenient that numerics are the same in C if it's not ideal. especially if we are interfacing with C
10:58:19    *   sepisoad joined #nim
11:02:23    Araq    *shrug* do what you think is reasonable
11:02:58    Araq    obviously it's important to be able to habe 2^64-1 inodes as 2^63-1 would be too few of them
11:03:06    Araq    *to have
11:03:36    czr for inode numbers it's actually somewhat complicated. on some filesystems they should be treated as unique identifiers for inodes (the fs will allocate them), on others you can actually discern some .. meaning of the value (ext-family)
11:03:37    *   sepisoad quit (Read error: Connection reset by peer)
11:04:13    czr so yes, it's quite possible and within POSIX spec to allocate an inode "number" that has highest bit set. however, since it's to be treated as opaque data, it probably doesn't matter.
11:07:54    gokr    Btw, debugging huge.nim works great in QtCreator.
11:08:09    czr the only operation that is "useful" in userspace with inode "numbers" is comparing two inode numbers for equality. any other operation is meaningless really.
11:08:19    gokr    It can also use the nim syntax highlighter for Kate.
11:10:11    Araq    czr: exactly, thank you.
11:10:30    czr np, sorry for barging in :-)
11:11:37    czr however, if you're providing an interface for existing linux/posix API, the path of the least surprise for the user of the interface is retaining exactly the same types, unless you're attempting to hide the underlying API. for FUSE it doesn't seem like a good idea
11:11:55    czr akiradeveloper, ^
11:12:36    czr akiradeveloper, btw, are you wrapping libfuse or talking fuse directly with kernel?