Thread by @uchujin17

C言語では文字列処理の実装にいちいち個性が出る。これはCという言語の文字列実装が貧弱すぎ(char*としてしか扱えない)、string.hで提供されている標準ライブラリも貧弱すぎるのが悪いと思っている。

まず文字列領域を配列で取るかmallocで取るかで分かれる。その大きさをchar strbuf[256]と直接書くか、#define STRBUF_SIZE 256とかマクロに書くかで分かれる。そのマクロを.cのほうに書くか.hに書くかでまた分かれる。

文字列バッファ長を変える可能性を考えて#ifndef STRBUF_SIZEと囲うか、strbuf_sizeを引数に追加するか。引数の型をintにするかsize_tにするかでまた分かれる。そもそも文字列を扱うのにいちいち最大長を考えなきゃいけないC言語の仕様が悪いんだけど、それを言っても始まらない。

込み入った文字列をレンダリングするのに、部分ごとに作ってstrncat()で接続してゆくか、snprintf()でまとめてレンダリングするか。あるいはファイル出力前提としてprintf()で吐き出すか。僕が好んだ手法は部分毎の結合で、しかもstrncatではなくstrcpyを使う方法だった。

char buff[256], char *p=buff, int bufsize=256みたいにして、
atoi(tmpbuf, value); len=strlen(tmpbuf); if (bufsize > len) { strcpy(p, tmpbuf); p+=len, busize-=len; }みたいにつなげてゆくの。これは癖みたいなもので、strncat()やsnprintf()に対して優る理由は特に無い。

DOS用コンパイラに付いてくるライブラリはリエントラント性の保証が無かったので使いたくなかった、str(n)catは毎回「コピー先文字列の長さ」を内部で数え直すのが嫌だった。それだけ。GHzで動きGByte単位のRAMを持ちプロセス空間で動くLinuxでは意味は無い。

自前printf()を作っても良かったんだけど、90年代はじめの組み込み用コンパイラは可変長引数の実装が怪しいのが多くて、va_arg()とかvar_start()とかのANSI標準ではなく独自文法だったり、ANSIですらなくK&R仕様で自前可変引数を実装できない処理系もあった。ANSI-C制式仕様が89年だものね。

そのスタイルをLinux上のコードで真似されているのを見るとorzだよ～。