C言語なら俺に聞け 164

(新スレ立ての際上記コマンドを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言語なら俺に聞け 163
https://mevius.5ch.net/test/read.cgi/tech/1721137434/

---

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

文字を扱うならcharを使うべき
signed charだのunsigned charだのは1バイトの整数型と思った方がいい

7ビットでおさまる文字は良いけれど
上位ビット立っている文字種は困らない？

お前時間止まりすぎだろ
そんな語り尽くされた話を今気づいたかのように話を始めるのやめろ

>>357
文脈を読んで。
整数やビットパターンとして扱いたいときの話をしてる。
文字の表現方法に踏み込まない不透明なオブジェクトとして扱える場合なら char でいいよ。

K&Rの段階でcharはunsigned型と決めてやればよかったのに

俺に言われても

アセンブラのラッパーだから型がいいかげんなのは仕方ないんだよ

charは8bit型ってことだったんじゃね

>>364
char のサイズは CHAR_BIT ビットだよ。

まあ、CPU毎に違うからな

charが8bitじゃないCPUなんて今現在市販品であるか？
DSPぐらいだろ

>>357
>>360
u8, i8, char

>>367
要するにCPU依存なんだって自白してるよね？

>>367
ほとんどないってことと規格として決められることは別じゃないかね？
この先も8bitとは限らないわけだし

話の流れでK&Rの段階の話だと思ったんだけど
そこ頃からCHAR_BITってあった？

>>369
DSPをCPUとはいわないんたけど
役割違うよね
そんなことも知らないの？
ちなみにどこのカス業界にお勤め？

>>372
世間知らずは世にあるCPUのどれだけを知ってるのかw

>>373
お前がCHAR_BITが8じゃない現役CPUを一つあげれば勝ちじゃん
言えない時点で負けじゃん
やっぱカスじゃん

>>371
K&R (初版) を基準とするのだとしたら CHAR_BIT は無いが char が 8 ビットとは限らないことは明記されている。
というか主要 (?) なアーキテクチャでのサイズが表で書かれている。
　・　DEC PDP-11
　・　Honeywell 6000
　・　IBM 370
　・　INterdata 8/32

規格化されて以降の文面では char (1 バイト) の大きさは「アドレスを振ることが可能な単位」であることに意味があるように読める。

>>375
そうなんだね
てっきり1Byteは8bitだと思い込んでた

僕の持ってるK&R2ndの表紙には紙テープを逆コの字に折ってCの文字を表現してたけど、テープは6ビットだったな

なるほどあれは紙テープだったのか
1バイト6ビットともなるとアルファベットは小文字だけ、記号は一部トライグラフを活用していそうな世界

>>378
昔は出版用 (紙面用) とコンピュータ入力用が違う表現を持つことも普通だった。
Wikipedia のストロッピングの項目の中に ALGOL68 の異なる表現の例があるのが分かり易い。
https://w.wiki/NbxY#Examples_of_different_ALGOL_68_styles
機種ごとの違いが大きい時代だとダイグラフやトライグラフをプログラミング言語に盛り込むよりは機種ごとのストロッピング規約で運用するほうが自然だったかもしれない。

K&R 初版で言及がある四機種を先述 (>>375) したが、この内で Honeywell 6000 が採用していた文字コード (で表せる文字セット) には波括弧が無かったらしくダイグラフでなんとかしていたらしい。
K&R に説明を入れてないのはその時代にはそういうこともあるというのは説明するまでもない普通のことだったからだろう。
もちろん機種個別のマニュアルには書いてあったと思うけど資料を見つけられない……

>>379
さすがだなあ
１バイトが６ビットのマシンで開発した経験とかあるの？

>>380
実際にその時代のコンピュータに触ったことはないが、 Scheme (Lisp 系言語のひとつ) に関心ある者として原初の Lisp が実際にはどのように入力されていたのか調べたことがあってストロッピングの概念は知っていた。
個々の機種がどのような文字コードを使っていたのかは今調べた。

>>379
へぇ～、同じ言語にも訛りで対応とは想像できなかった

Cはなかったが36ビットがワードなコンピュータなら触ったことがある
ASCIIは9ビットでクォーターワードという扱いでワード内に4文字入れていた
TSSもあったがバッチ処理はパンチカードで紙テープはそれ以前の時代

昔ROM焼いてもらうのに紙テープで持ち込んだ

charサイズの話が出ていたけど、1バイトがが8ビットと定義されたのが21世紀に入ってからと言うのに、大いに驚いた。
私は80年代初頭にベーシックマスターJrという機種で入門したのだけど、パーソナルな世界では8ビット以外見たこと無かったので・・・。
それ以外のサイズはどこか遠い世界の話だと思っていた。
そもそもコンピュータは趣味なので業務用機の世界をまるで知らないのだけど、8ビット以外は(今も？)当たり前なの？
それでもコードを使い回せるC言語もすごいなあ。

漢字も一文字１キャラクターで扱える言語があったような

MSX-BASICでは1バイト文字コード0x80以降に割当てされた漢字や罫線、トランプ記号がそのまま扱えたね
パソコン自体の規格であり、キーボードからの直接入力も可能、GRAPHキーと組合せて押下H/M/S/¥
が時/分/秒/円に対応等だ

松下だっけか?力入れてたの

>>385
ネットワークの世界だと7ビットだったからな

>>385
きっと嘘だと思う
どうしても議論に負けたくなかったとかなんじゃね

初期のパソコン通信では使用する端末の制約で
漢字こそ扱えなかったが、半角カタカナは扱えてたよ。
その性でujisとは相性が悪かったな。

8 ビットを一塊にすることを明瞭に表したいときのためにオクテット (octet) という単位があって、ネットワーク系の規格では今でも使われてる。
新しいところだと HTTP/2 あたりでも。
https://datatracker.ietf.org/doc/html/rfc9113
1 バイトが 8 ビットとは限らない時代のなごりだね。

ネットワーク系ではたぶん割と初期から 8 ビットを単位にしてたと思うけど 1 ビットをパリティに使ったりとかで全体をデータ用には使えなかったりはした。

4bitCPU全盛の頃は既に
1byte=8bitsという概念だったのだろうか
4004の機械語で具体的に解説してくれ

他でやれよ

4bitCPU時代にはC言語は存在しなかったんじゃね

UNIXはワークステーションだからな

PDP11:1970〜
i4004:1971.11.15〜
C言語:1972〜

4004用のosはなかったと思う
osのない環境でコンパイラは無理ではないか？

C言語のint型は16ビットだった
標準化以降は環境依存ではあるが、short int型と明記することになった。

なんかパソコンを前提としたCPUの話は違和感しかない。

intのサイズはCPU依存だったと思う

>>398
PCしか知らないゆとりか？
PCのセルフが例外的であって、PC以外ではほぼクロスだぞ

4004のクロスがあるなら示して

>>402
こういう噛み合わないことを言い始めるのを見るとイライラするから指摘しておくが、文脈を読んで。
>> 401 は「OS のない環境で」ということに対してそんなことは理由にならんという主旨で書かれてる。
4004 のクロス開発環境が実在するかどうかは重要ではない。

4004って1981年には製造終了してますけど

>　4004シリーズLSIの開発が終了し，1970年11月下旬に帰国した。
>私の本来の仕事，プリンタ付き電卓の開発が始まった。

>　ただ，プログラミング言語の開発までは手が回らず，
>プログラミングには機械語を使用した。インテルでは，
>電卓用プログラムの完成後にROMのマスク情報をインテルに
>渡す手段を用意できなかった。そこで，プログラムの
>マシンコード（命令）や定数に相当するROMのバイト情報を
>ROM内のマスクに対応する位置にマークを付け，ROMのマスク
>情報をインテルに送ることを決めた。

>　最終的な電卓用プログラムを作成し，1971年3月に完成した。
>プログラムの総容量は1Kバイト以内だった。電卓の応用
>プログラムは約250バイト，電卓向けマクロ命令用プログラムは
>約400バイト，電卓向け言語用インタプリタとキーボード制御と
>プリンタ制御は約350バイトとなった。平方根演算機能は
>オプション機能とした。

https://xtech.nikkei.com/it/article/Watcher/20070702/276468/
嶋　正利

当時4004で使えた開発ツールはMSのマクロアセンブラくらいです。

>>400
それはあなたが知らなかっただけ
ANSIではint型は32ビットではなかった

>>400
それはあなたが知らなかっただけ
ANSIではint型は16ビットではなかった

i4004でインタプリタとかマクロとか既にあったんか
ていうかi4004がPDP11より後なのはびっくり

C言語ができる前のUNIXの話を持ってくる人間は意味のない話をしていると思う。

どんなにがんばっても1バイトを7ビットってことにするのは無理そう

CPUが7bitレジスタ仕様でないと作る意味がなさそう。

当時はデータ部7ビットの通信データとCPUが扱う8ビットのデータどちらもバイトと呼べて楽でしたよ

いきなり通信プロトコルの話？

はい、1バイトのビット数の話題が出ていたようでしたので、それに関わる通信処理絡みの話でした

C の規格としては、昔はともかく ANSI 以降は 1 バイトは 8 ビット「以上」ということになってる。
もしハードウェア的に 7 ビットが単位になるようなアーキテクチャだったら C の規格に準拠するには 2 つまとめて 14 ビットを 1 バイトという扱いにするしかない。
規格準拠を諦めたほうが楽だと思うけどね。

>>416
数値でも最上位の1ビットを符号にしている時点で7ビットでやりくりしていると認めないと

虚数も扱えると良いね

C に虚数型 (_Imaginary) はあるよ。
オプショナルな規定だから無い場合もあるけど。

>>417
正負を合わせたら8ビットでは

N81XとかN71Eとかかな

チートエンジンのエンティティリストのアドレスとオフセットってなんですか？
この二つを足すとポインターアドレスになりゲームを再起動しても普遍のアドレスになるみたいなんですけど

AI時代に国語力のないやつ

チートエンジンてこれのことかな？
https://www.cheatengine.org/
うさみみハリケーンと OllyDbg で満足してたから知らなかった……
よいソフトを知った。ありがとう。

メモリって malloc とかで確保するわけだけどそれって起動するたびに違うアドレスだったりするでしょ。
でもその確保した中でのメモリのレイアウト (それぞれのデータのオフセット) は普通は同じようにする。
だからベースアドレスとオフセットの組で扱えば便利だねってことだと思う。

セグメント、オフセットという話なのか？

リアルモードで動くプログラム久しぶりに聞いた

アドレスのランダマイズ対策だろ
ゲーム改造していきりたいキッズだから無視でいい

ツールのドキュメントの頭のほうにサポート対象が Linux, Mac, Windows って書いてあるでしょ。
いずれもリアルモードでは動かない。

ランダマイズというわけでなくてもポインタを辿る必要のあるデータ構造というのはごく普通にある話だろう。

仮想メモリでもセグメント(と言っても間接になるけど)とオフセットだろ

>>417
1バイトの中に符号を加えてはならないという決まりはない

>>430
正確には負の数を表現するときに1ビットを使うというだけの話

その辺はCPUが提供する命令セット次第

CPUが提供するという言い回しが奇妙

まあ、キャリーフラグやなんやら考えたらCPUが提供するってのはあながち間違いじゃ無いからねぇ

符号つき整数の内の 1 ビットが符号ビットであるというレイアウトは C の仕様として保証してる。
それを各 CPU の命令セットの範囲内でどう実現するかは知らんけど。

>>435
CPUそのものにあるかどうかは別にして3D計算だと負の数専用の命令やレジスタは存在しているんじゃないのか？

その想像で存在を仮定して質問するのはどういう知能なの？

C言語の仕様とハードウェアは関係ないからな

コンパイラがハードウエアと無縁だなんて、初めて聞いた

何のための2の補数…

>>436
ここでは C の仕様の話であることを強調する意図で CPU のことは知らんと述べた。
命令セットの中に有ろうと無かろうと符号つき整数の内の 1 ビットは符号ビットだ。

また1バイトは7ビットだって言ってるキチガイがいるの？

C言語にキャリーフラグの状態を取得する関数が無いのはなぜですか？

自分で作る
Cに出来ないことはない

signed と unsigned があるやん
で、どちらも８ビットだよん

>>444
できることと効率がいいかどうかは別物

効率の良い方法でどうぞ

>>443
C#とかさ、オーバーフローしたらエクセプション出して落ちるけど
あれ、地味に要らない機能だよなって思う

>>443
標準になってないが普通コンパイラがintrinsic提供してる
高速な多倍長整数を自作できてようやくC言語中級レベル

>>448
それはお前がエンジョイ勢だから

>>449
足し算引き算はなんとか
かけ算も頑張ればできそうな
割り算は、ちょっとやっかいかも

かつてubasicというソフトがあって、
今もあるかは調べていないが、
多倍長演算が出来て、結構使える。
πを1000桁まで計算するサンプルが掲載されていた。

開発効率より実行速度命やろ

今でもCに固執する変態は実行速度命

世界を変革しているのは変態パワーだぞ

>>439
C言語の仕様は抽象マシンにおいてどう動くかという形でしか定められていない
コンパイラはそれを環境に合わせて自由に実装することが許されているので、コンパイラの仕様はC言語の仕様では定められていない