C言語なら俺に聞け 161

2023/04/21(金) 14:05:20.18

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C17
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

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

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.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言語なら俺に聞け 160
https://mevius.5ch.net/test/read.cgi/tech/1672191630/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/08/24(木) 00:03:34.65

>>523
Win16でmallocなんか使ってたらころされてしまいますよ

2023/08/24(木) 00:24:02.15

そこでfar pointerです

2023/08/24(木) 00:43:25.45

16ビットで十分なハンドル値をnearポインタにキャストするというのはいいアイデアだった

2023/08/24(木) 00:56:52.45

あぁなるほど!
16bitの頃のMSの貧弱な開発環境で育ったせいで
標準Cに対しては屈折した気持ちのままなのねw

2023/08/24(木) 01:06:43.62

標準ライブラリは古いつーか実環境を考慮してないだけでbit数はあまり関係ない…
理解してないのに無理に話に入ってこんでもいいぞ

2023/08/24(木) 01:26:43.52

>>526
いや、初期のマイクロソフト知らないのかよw
闘うプログラマーとか読んでみろ
めちゃくちゃおもろいよ
そんなことも知らないとか、モグリも大概にしろ

2023/08/24(木) 01:40:06.60

macOS(iOS)のアプリ作る時は、OPENSTEP由来のFoundationフレームワークを使うだろ
こうなるとprintfも使わずにNSLogばっかりだなw

2023/08/24(木) 02:24:55.77

そもそもC言語で新規開発すること自体がほとんどないので標準ライブラリ使うかどうかは今となってはどうでも良い。

**デフォルトの名無しさん** (ｽﾌｯ Sdb3-G+yN) · 2023/08/24(木) 07:36:25.07

macOS以前のmacのCはもっとひどかった黒歴史

2023/08/24(木) 12:16:23.79

>>532
その手の本を本気にするなよ恥ずかしいｗ
小説だぞ

2023/08/24(木) 12:58:04.14

>>536
それで煽ってるつもりかよw
知らないなら黙ってろよ

2023/08/24(木) 13:05:10.53

闘うプログラマーをディスる奴が居るとはな
さすがモグリは違うw

2023/08/24(木) 16:07:54.33

お前の聖書を貶されて怒るのはわかるが
ただの宗教を他人におしつけるなｗ

2023/08/24(木) 17:35:21.45

「綺麗なのは使われてないものだけ」みたいな格言をどっかで見た。

2023/08/24(木) 22:11:17.69

闘うプログラマー懐かしいな
随分と前に上下巻の頃に読んだ

うろ覚えで申し訳ないがwinodwsのAPIセットを考えるのにカトラーと幹部がクルーザーを1～2週間借りて
湖でクルージングしながらゆっくり考えたってところが印象的

クリエイターって感じで良かった

2023/08/24(木) 22:22:10.52

残りの人生がどれだけあるか知らないけどそういう環境でそういう仕事してみたいなと思う

2023/08/24(木) 22:45:31.31

C言語の開発って、
ジャングルの中、誰からも支援を受けずに
自給自足で生き残って敵に勝つイメージがあるな
必要な道具は自分で作るみたいな
恵まれた環境で使うには難しい世の中になってきた

2023/08/24(木) 23:08:24.66

闘うプログラマー読んだことないモグリだけど
カトラーがDECから来る前からWindows APIはあったよね？

2023/08/24(木) 23:36:03.41

Windowsは1.0からあるからなあｗ

闘うプログラマーはNTの開発物語
カトラーが関与したのはWindowsNTのAPIセット

2023/08/24(木) 23:47:18.67

カトラーが実装したのはカーネルレベルのAPIでしょ
Win32はその上にある

2023/08/25(金) 00:02:25.25

win32はもともとWindows NTの機能だよ
それにカーネルだけ実装してWindows NTを発売したとは思えないけど

3.1とかはwin16
ついでNTでwin32
そのあと95が出てくる

2023/08/25(金) 00:08:33.68

フリーセルはWIn32sで動いていたんだよな

2023/08/25(金) 00:18:17.29

あの頃はネット接続も一般的ではなかったから Win32s は雑誌の付録とかの形でよく入ってたのを覚えてる。
俺はテックウィンの付録CDから入れたわ。

2023/08/25(金) 07:12:39.12

>>533
macOS（Mac OS X)になって、旧Mac OS由来のCarbon APIのサポートのため
Foundationの下にCoreFoundationというCの共通ライブラリが作られたよね
すなわちC言語が基礎と。おそらく今でも
Carbon亡き今、CoreFoundationを直接使う必要はほぼないけど

書式出力は文字列のクラス（NSString/CFString)に含まれるというべきかな
NSLogも書式出力を受け付けるが、元々ログ出力関数なので

2023/08/31(木) 01:23:37.12

Cの規格書の 7.15.1.1 va̲arg には以下の記述があります。

次の実引数が実際にはない場合，又は型が実際の（既定の実引数拡張に従って拡張された）次の実引数の型と適合しない場合，次に掲げる二つの場合を除いて，その動作は，未定義とする。
－一方の型が符号付き整数型であり，もう一方の型が対応する符号無し整数型であり，
そしてその値が，両方の型で表現可能な値である場合。
－一方の型がvoid型へのポインタであり，もう一方の型が文字型へのポインタである場合。

これは例えば、可変長引数をとる関数にNULLポインタを渡し、呼び出された側で

　FILE *fp = va_arg(ap, FILE *);

として受け取ってはいけない、という事を指すのだと理解しています。
なぜこのような規定が設けられたのでしょう？

2023/08/31(木) 04:18:42.26

>>551
実引数と適合しない型で取り出す場合の組み合わせは無数にあり、
多くは無意味でそのすべてについて結果を規定するのは大変だし必要無いので
最低限必要と思われる範囲で動作が規定されている、と考えれば自然。

2023/08/31(木) 06:17:20.33

>>551
そこで規格がしてるのは特定の事柄を想定した話じゃなくて、単に責任の所在について言及してるだけだよ
va_argで指定する型と実引数の型を合わせるのはユーザーの仕事だ、合わない場合は動作を未定義にするよってこと
C FAQ 11.34を参照のこと

また、2つの例外事項はその部分はコンパイラ側が推測して補正出来る事項なのでそこは許容するよってこと

2023/08/31(木) 08:59:50.92

>>551
NULLポインターはFILE*と適合(compatible)してるから問題ない
そこに書いてあるのは適合しない場合の事

**551** (ﾜｯﾁｮｲ 4d20-lN7b) · 2023/08/31(木) 19:57:18.34

多数の回答ありがとうございます。
おおむね、先に挙げた例に対しては「問題ない。規格に適合している」とのご意見のようです。
しかし、先に挙げた問題を解決することを目的（の１つ）として、C23では新たに nullptr 定数が設けられる、とも聞いています。
実はそもそも「そんな問題などなかった」という事なのでしょうか？

2023/08/31(木) 21:01:54.47

「逆に」とか「実は」とか中二病は好きだよね
その規格書の文章が判りやすいとも思えないから好きに解釈していいよ

2023/08/31(木) 21:03:14.12

クソどうでもいい。現実の問題を正しく定義しろカス

2023/08/31(木) 22:30:14.55

>>554 >>555
私の解釈では規格に沿っているとは言えないと思う。

C では整数定数としての 0 は特別な地位にあって空ポインタの定数としても使えるので
#define NULL 0
といった定義でも言語仕様を満たすし実際にこういう定義になっていることも多いのだけれど
状況によっては単に整数と解釈されてしまうことが問題になる。

可変長引数で FILE* を期待しているところに空ポインタを渡すのは許されるが
NULL と書くと (それ単体では整数型なこともあるので) ポインタとは適合しないことがあり得る。
仕様に厳密に言えばその場合の実引数は (void*)0 とか (void*)NULL とか書かないといけない。

大抵の処理系では問題にならないように上手いこと調整されている。
#define NULL 0LL
みたいな感じで (その処理系における) ポインタと同じサイズの整数で定義しておけば一般的な ABI では大丈夫。
(だが言語仕様で保証しているわけではない。)

NULL は整数とポインタを兼ねる (ような定義でも許される) というのが
歴史的経緯によるあまりにもグダグダな場当たり的な規則なので常識的に考えてあかんやろという話。

2023/08/31(木) 22:30:45.52

>>555
＞として受け取ってはいけない、という事を指すのだと理解しています。

君のこの理解が間違っていた
それだけでしょ

2023/08/31(木) 22:49:56.13

>>554,555
可変長引数として渡したオブジェクトポインタは実引数拡張により全部 void* になるから、
typedef void FILE; とでもなっていない限りは適合するとは言えないよ。
va_arg(ap, FILE *) として受け取ってはいけない（移植性を損ねる）ということで合ってる。

そもそも適合は型と型の関係だから「NULLポインターはFILE*と適合」はおかしい。

**551** (ﾜｯﾁｮｲ 4d20-lN7b) · 2023/08/31(木) 23:05:28.70

>>558
処理系によってはNULLが (void *)0 でなく、
0 と定義されているかもしれない（から駄目）という事ですね。
納得しました。ありがとうございました。

2023/08/31(木) 23:08:37.85

>>560
よく確認してみたら確かにそうだわ……。
NULL が整数として解釈される可能性を考えるまでもなく
void* と FILE* は適合しないな。

ポインタが適合する条件としては同一の修飾がされていることに加えて
両者が適合する型のポインタでなければならないことになってる。
void と FILE は適合しないのだから void* と FILE* が適合することもない。

**551** (ﾜｯﾁｮｲ 4d20-lN7b) · 2023/08/31(木) 23:38:40.05

NULLについては納得しましたが、まだ疑問が残っています。
同じポインタ型であっても、保証されているのは、
「一方の型がvoid型へのポインタであり，もう一方の型が文字型へのポインタである場合」
だけとなっています。この制約の意図が不明です。

例えば、可変長引数をとる関数に (void *)NULL を渡し、呼び出された側で

　FILE *fp = va_arg(ap, FILE *);

として受け取るのも不適合に思えます。

この場合でも、(例えば)アライメントの問題があり、互換が保証できるのはvoid型へのポインタと文字型へのポインタだけ、といった事なのでしょうか？

2023/09/01(金) 00:09:17.26

>>560
適合しない場合ってのは、FILE*とint*とかを言うのだろう
void*とFILE*は適合しないのか？
それとNULLを0なんかに定義してたら、NULLはintとしか適合しなくなる
なのでNULLポインターは((void*)0)と想定している

2023/09/01(金) 00:20:09.48

>>563
適合する型なら許されるということに「加えて」
void* と char* の組み合わせの場合でも許されるという
規定になってるのはわかってる？

>>564
ポインタの適合に関するルールは C99 なら 6.7.5.1 に規定があって
void* と FILE* は適合しない。

> それとNULLを0なんかに定義してたら、NULLはintとしか適合しなくなる
> なのでNULLポインターは((void*)0)と想定している

・値0をもつ整数定数式又はその定数式を型void *にキャストした式を，空ポインタ定数（null pointer constant）と呼ぶ。 (§6.3.2.3)
・ NULL は，処理系定義の空ポインタ定数に展開する。 (§7.17)

とあり、 NULL が整数的数式の 0 であることは許容される。

**551** (ﾜｯﾁｮｲ 4d20-lN7b) · 2023/09/01(金) 01:19:09.35

>>565
適合する型なら許される、という点は理解しています。
しかし「void* と FILE* は適合しない」のであれば、
>>563 の例も不適合ではないでしょうか？
また、不適合であっても void* と char* の組み合わせ
の場合なら許される理由は何でしょう？

2023/09/01(金) 01:43:08.25

>>566
総合的に言って不適合という理解で正しいということになる。

void* と char* は適合の規則からすると適合ではないのだけれど、
その表現や境界調整は等しいことを保証する規則があるので
この場合に適合と同等の扱いをしても問題にならないから、
まあ出来るようにしておけば便利なこともあるんとちゃうんかなぁ。

2023/09/01(金) 02:40:24.68

>>565
ポインターに0の代入は問題ないけど、ここでの話は可変個引数に渡した時の事を言ってるので((void*)0)じゃないと不味いでしょ

2023/09/01(金) 02:50:24.64

>>565
6.7.5.1では、FILEとvoidが適合しないといけない旨の記述があるけど、voidというのは普通に比較して適合かどうか判定できる型なのか？
特別なルールが有って然るべきな気がするけどね

2023/09/01(金) 09:38:35.84

>>568
不味いけど NULL が 0 のことはあるという話。

2023/09/01(金) 18:08:19.15

何の話をしてたんだかよくわからんようになったので >>551 を読み返してたんだが
規定が設けられた理由が根本的な疑問ということでいいんかな。

当然だが引数を受け取る側の想定と異なるものを渡したら破綻する。
普通の関数ならコンパイル時に受け取る側と渡す側の型の間に不整合が合ったら
コンパイル時に検出できるし、条件に合えば暗黙の変換もするんだけど
可変長引数の場合は実行時にならないとわからないので
調整する必要なく渡せる条件を規定したらそうなったって感じだと思う。

整数は負数が絡まなければ同じ表現だし
void* と char* にも互換性があることも保証されているので
問題にならない。

2023/09/01(金) 19:53:17.39

ポインタ苦いか塩つぱいか
そが上に熱き涙をしたたらせて
コードを書くはいづこの里のならひぞや

「まずい」や「拙い」でなく「不味い」と書かれると、つい...

2023/09/01(金) 20:42:45.29

メモリの先頭をいじっている時点で頭がおかしいが

2023/09/01(金) 21:08:05.68

ヌル文字の実体が数値のゼロということから思いついた理屈なのかな？

ポインタはアドレスで、そのアドレスに格納されている値のことではない。

**551** (ﾜｯﾁｮｲ 4d20-lN7b) · 2023/09/01(金) 21:13:54.66

>>571
色々ありがとうございました。

素朴に考えて、呼び元がポインタを渡し、
それを呼び先がポインタとして受け取れば
（それが何型へのポインタであろうとも）
普通に安全そうに見えるのに、何でこんなに厳しいのか？
そう決まった理由が知りたかった為の質問でした。

誰か、そこら辺の事情を知っている人はいないか？と。

2023/09/01(金) 21:37:10.15

>>575
C言語のポインタは単にアドレス

ただし、構造体なら構造体、関数なら関数で、メモリ上に決まった配置をされるので、なんのポインタかわからないと、メモリのアドレスをずっと追いかけることになる。

コンピューターそのものにはデータ型というものは存在しない。

2023/09/01(金) 22:14:19.34

>>575
単純にアラインの問題じゃないの
char型なら１バイト単位だからどんなアドレスでもOKだが
それ以上のサイズの変数へのポインタは他のポインタへ変換できない可能性があるというのがたてまえで

2023/09/01(金) 23:22:02.51

>>575
ポインタの表現は、それが指す先の型によって異なることも言語仕様としては許されるはず。
§6.2.5 でポインタの表現や境界調整要求が等しくあるべき条件が規定されていて
それ以外の条件では同じ表現または境界調整要求を持つ必要はないと書かれてる。

まあそんなアーキテクチャがどれくらい存在するのかは知らんけど

2023/09/02(土) 00:36:03.53

いやいや、ポインター(アドレス)自体はアライメントされてない所に格納されてるかもしれんけど、中身のアドレス自体は問題ないアライメントになってることが保証されてるでしょ
オマエらは何を言ってるんだ？

2023/09/02(土) 00:41:32.42

farポインタみたいにバイト数の違うポインタも混在していたら余計にややこしい問題に・・・

2023/09/02(土) 01:01:48.59

例えばFILE*とshort*ならアドレスのアライメントが合わない場合があるだろうけど、これはそもそも型が適合しないわけでどうしようもない
でも、今考えたらvoid*はありとあらゆるアドレスを取る可能性が有るから、それに合うのはchar*しかないよ、ということを言いたかったのだろうなと気付いた
でも規格書を見ても、FILE*とvoid*が適合するかどうかはアンドキュメンテッドだなw
現実には((void*)0)とFILE*は完全に適合してるけどね

**551** (ﾜｯﾁｮｲ 2320-+GqY) · 2023/09/02(土) 06:58:16.01

ここにこう書いてあるからには、何か（通常の関数呼び出しでは
問題にならないが）可変長引数特有の問題があり、
それを避けるためにこうしたのだろう、と思った訳です。

2023/09/02(土) 11:49:29.07

>>579
そんな保証はまったくない
例えばmallocの場合戻り値は「あらゆる組み込み型に対応できるようにアラインメントされる」と特に注釈されている
逆に言えばvoid*はどんなポインタにキャストしても安全と思い込みがちだがそんなことはないということ

>>582
通常の呼び出しなら型チェックが働くが可変長呼び出しでは一切働かないという注意だろう
最近のprintfは型チェックされるようになってるけど

2023/09/02(土) 11:59:23.66

安全かどうかは、環境によるんじゃ

2023/09/02(土) 12:34:31.87

「環境による」のは安全ではないんだよ
ここで取り上げられてるのは大元の公式文書なのであらゆる環境について言えることが書いてある

2023/09/02(土) 12:59:05.22

マイナーなCPUのことなんか気にしたことがなかったな

2023/09/02(土) 13:12:11.45

>>584
現在の文脈では「言語仕様をそう決めた理由」が主題。

だからその前提として言語仕様が保証している範囲がどこまでかを
理解しておく必要があって、そこで見当違いの主張に反論がされている
という話の流れ。

2023/09/02(土) 14:05:43.49

>>586
「可搬性」という概念はCでは大事
マイナーなCPUのみならず将来的に登場する高性能だが制限が多いCPUでも手直しせずに動かせるということもあるかもしれない

2023/09/02(土) 14:41:25.26

必要なら環境依存なことをしやすいのも C の良いところだが
不必要な依存は避けるに越したことはないわな

2023/09/02(土) 14:45:40.34

FILE *fp = fopen(...);
void *hoge = (void *)fp;
FILE *fuga = (FILE *)hoge;
みたいなことは禁止されてる？

2023/09/02(土) 14:59:50.63

どうしても必要ならやるしかない
ただfopenの戻り値でFILE構造体の安全性が保証されてるのにわざわざvoid*に代入してからFILE*に戻すのは
正統な金なのに闇銀行に預けて再びマネーロンダリングするような変な手間だ

2023/09/02(土) 15:08:48.05

void *型って参照する先の変数のサイズが不明なので右辺値になるのは不可能な気がするけどな
キャストは無理でしょ

2023/09/02(土) 15:12:41.39

>>590
オブジェクトを指す (つまり関数ポインタではない) ポインタを
void* に変換してから元の型に変換すると
元のオブジェクトと等しいことは保証されている。

2023/09/02(土) 15:26:23.14

>>592
void じゃなくてもいいや
FILE *fp = fopen(...);
char *hoge = (char *)fp;
FILE *fuga = (FILE *)hoge;
みたいなことは禁止されてる？

2023/09/02(土) 15:40:22.87

>>592
なんで？
ポインタはメモリ上の一点を指すもので
インクリメントデクリメントが不可能なだけで
キャストは可能

>>594
いったい何が聞きたいんだ？
禁止はされてないよ
ただこれ見たプログラマは皆「バカだなあｗ」とは言うだろうｗ

2023/09/02(土) 15:52:38.82

言葉をちゃんと使うとプログラマ意思疎通がよくなるのでは。
「void * が右辺値になるのは無理」って何だよ。ではなく、正常動作はプログラマの責任になる、って言いたかったんじゃないの？

>>590 みたいなコードは、これだけなら疑問に思うだろうが、こういうコードが有効になる事はあるよ。その一例は

「ここで言うFILE* みたいなモノが複数種類あり」
送信側 - 中継機能 - 受信側
のプログラム構造で送受信のペアは複数あり、中継機能には実際の中身が何なのかは意識させたくない。

----
ポインタの話から外れて恐縮だが、
例としてタグ・レングス・バリュー形式ってのがあって、「中継者は送受信データがTLV形式の連続であることだけは知っていて」「TとLのサイズは一定」「タグの種類が何種類あるかなんて知らなくていい」
----

これにさらにポインタを含むデータ構造を通信可能にするには？って話で、ポインタ型をバッファ内インデックス値に変換して、ポインタが指す中身も通信データに含める、とか、
サブ構造がポインタ持ってたら再帰的に処理する、とか話は続くが
それはいいとして

>>590 みたいなコードは、現実にはあるよ。という話

2023/09/02(土) 16:04:16.63

>>594
オブジェクトを指すポインタは char* (またはその他の文字型をさすポインタ) へ変換することは許されるし文字配列として読んでもよい。 (読んだ結果としてどういうレイアウトになってるかはわからんけど。)

そしてもとの型に型変換したら変換前と等しいことも保証される。

2023/09/02(土) 16:06:19.94

たしかに言い方が悪かったので

>>592
ポインタは元々サイズは無いもので
対象オブジェクトの先頭アドレスの一点だけを指してるから
void*を含むどんなポインタもキャストすれば力づくで代入できる
ただvoid*にはサイズがないのでinc dec(加減演算)をしようとするとエラーになる

>>594
どんなキャストも禁止されてはいないが
プログラマの責任によって成される最後の手段だと思ったほうがいい
見つかりにくいバグの原因になるので
ソースにコメントで理由を明示しておいたほうがいい

2023/09/02(土) 16:12:48.48

うーん
まだまだ添削できる余地があるぞ…

ここはまあ無料掲示板だが、仕事では、自分には誤解をされやすい性質がある、と意識しなされ

2023/09/02(土) 16:50:14.84

アハハ
なんだこの人ｗ

2023/09/02(土) 17:10:38.18

ここでお金稼ぎしている人いたっけなｗ

2023/09/02(土) 21:43:01.25

もりたぼ稼ごうとした人はいた

2023/09/02(土) 22:10:43.72

ポインタの宣言は、ポインタの型じゃなくて、ポインタが指しているアドレスの格納値をどう扱うつもりなのかを明示している。

void型のポインタは、ポインタだから、何型のポインタだから、64ビットだったり、32ビットだったりするものではない。

2023/09/03(日) 13:47:13.05

>>603
同じでなければならないという規定はない。
実際に異なる実装が存在するのかどうかは知らんけど。

2023/09/04(月) 07:48:03.87

>>594
void void * 登場前の C は
FILE *fp = fopen(...);
int *hoge = (int *)fp;
FILE *fuga = (FILE *)hoge;
だったんじゃないかな

2023/09/04(月) 07:53:14.39

設計当時はアセンブラの代替言語。

2023/09/04(月) 09:48:09.59

>>605

基本はcharだからchar *hoge = (char *)fp;じゃない
なんならint hoge = (int )fp;でもよかった
ほとんどの場合intとポインタのサイズが同じだった

2023/09/04(月) 10:04:32.23

>>607 みたいなのがいるから void が出来たんだよ

2023/09/04(月) 11:07:54.13

因果逆転だな

2023/09/04(月) 11:19:05.30

>>607
ウソはだめだ。
俺が見逃しても、はちみつ先生に定規でケツはたかれるぞ

2023/09/04(月) 11:24:33.03

そういえば、むかーしの情報処理試験には言語選択でマシン語ってのがあって、1メモリアドレス値が指すメモリは 8bit 幅ではなく、 16bit だったように記憶してる。
「特殊な環境を想定しやがって…」と思ったナカマいない？

2023/09/04(月) 11:27:19.73

試験用アセンブラはCASLだったっけ？
仮想環境で実在しない環境用言語だって。

2023/09/04(月) 12:00:00.02

>>610
char* はどのポインタからも変換できるし
元の型に変換すれば元のポインタと等しいことは保証される。
好ましいとは言えないが変換自体は問題ない。
void* 登場前には (void* 的なことが必要なら) char* が使われていたのは本当だ。

ポインタから整数へも型変換できることは明記されてる。
その結果は処理系定義だが、出来る環境でやるのが悪いわけじゃない。

char* やら int やらで扱ってたら間違った取り扱いをしやすいので
可能なら避けたほうがよくは有るが、 >>607 が言及した範囲には
明瞭に間違いと言えるものは見つけられない。

2023/09/04(月) 12:00:22.47

メモリが8bitって何も出来ないぞw

2023/09/04(月) 12:05:38.98

アドレス範囲ではなくてデータ長が16ビットだったと思う

2023/09/04(月) 12:09:35.09

>>611
C の仕様上の用語では「バイト」が 8bit とは限らない定義になっている。
C の仕様で想定する必要がある程度にはそういう環境もあったのだろうし、
主流ではないにしても特殊というほどの感じでもなかったんちゃうか？

まあ「昔」をいつ頃に想定するかにもよるだろうけど。

2023/09/04(月) 12:24:06.96

>>612
たぶんだけど >>611 が言うのは CASL の前身である CAP-X のことじゃないか？
16bit 単位でアドレスが振られる設計だったはず。

2023/09/04(月) 14:04:31.55

7bitでアルファベットは表せてたしねぇ
文字集合で完結させてた RFC822

2023/09/04(月) 20:56:26.82

実際に1バイトが8ビットじゃないマシンで仕事してた人いる？
経験談を聞いてみたい
つらそう

2023/09/04(月) 21:41:24.34

何がつらいの？

2023/09/04(月) 22:35:30.73

UNIXとか基本９ビットが見え隠れしてる気がする
ファイルのパーミッション---rwxrwxとか
C数値のデフォルトが8進数とか(9ビットなら8進数３ケタでまとまりがいい)

2023/09/04(月) 22:55:40.14

あれは９ビットだったのか

2023/09/04(月) 23:38:31.34

1バイト9bitとか完全に都市伝説だろ…
1ワード(レジスタ)が36bitとかはLispマシーンで使われたりしてたけどね

2023/09/06(水) 06:22:01.74

char が16bitの環境なら使ったことがある

2023/09/06(水) 07:02:16.45

そういうのってどんなCPUなの？

2023/09/06(水) 09:37:16.14

とりあえずDSPなんかはそうでしょ
ワードマシンって言っちゃっていいか知らんけど、演算の速度をあげるためにワード幅を一番使いそうなビット数にして全部ワード単位でアクセスする設計にしてる
マニュアルにアドレス、char幅、int幅全部同じ何々ビットです注意してねみたいなのがご丁寧に書いてあったりするよ