【初心者お断り】ガチ規格準拠C専用スレ Part133

このスレは標準C規格や規格に合致した移植性の高い記法・技法に関するスレです。
C言語初心者の初歩的な質問、GUIなどの標準Cではできない事の質問、
ソース丸投げ、宿題、書籍 などは専門の別スレッド↓があるのでそちらへ。

Ｃ言語なら俺に聞け（入門篇） Part 24
http://pc11.2ch.net/test/read.cgi/tech/1201083176/
【初心者歓迎】C/C++室 Ver.47【環境依存OK】
http://pc11.2ch.net/test/read.cgi/tech/1200464091/
C/C++の宿題を片付けます 103代目
http://pc11.2ch.net/test/read.cgi/tech/1200318925/

【書き込む前に】
・まず問題を冷静に吟味してCの話か否かをはっきりさせてから質問しましょう。
・質問する前には最低限検索を。
・エラー(警告含む)が起きたのならばエラーメッセージを書きましょう。

【参考文献】
C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/
Cプログラマ必読 ・プログラミング言語C(通称　K&R)
http://www.amazon.co.jp/exec/obidos/ASIN/4320026926/250-7563469-9920244

【このスレのログ】
前スレ：http://pc11.2ch.net/test/read.cgi/tech/1190261457/
他の過去ログ：http://nssearch.hp.infoseek.co.jp/clang/

【このスレ住人としての心得】
わざとスレ違いあるいはごく低レベルな質問を繰り返して
流れを妨害する荒らしがいます。適当に誘導して放置してください。

＜｀∀´＞ニダニダ！

>>2
こりゃ低レベル

>>1市ね

＞前スレ1000
こりゃひどい

なんぞこのタイトル

スレタイが不適切だという指摘と
最近のスレの傾向を鑑みて
適切なスレタイを考えてるうちに
スレがつぶれそうになったので
とりあえず前に書いてあったタイトルを修正してつけた

もっといいのがあるなら次からそれにしてくれ

確かにこういうスレも必要かも知れん

…が、そのスレの次スレとして立てるのは如何なモノかと思うぞ。

JISのPDFダウンロードできるじゃん
ってダウンロードしたけど、全ページ黒塗りだった。
なんとかしてくんろ

いいスレタイだな。
これなら流石にスレチは減るだろう。

先生, 質問!
はじめて, MS の処理系で業務に使うものを作る事になりそうなんだけど
規格準拠してる?
最低限でも, stdint.h とか stddef.h が規格準拠しててほしいわけだが…

>>11
VSスレ辺りで聞いてみてはどうか。

>>12 そもそもVSスレって何？？？
まじで, Windows ほとんど触った事ねぇし
俺的には Windows == ユーザが要求してくる使いたくもない MS-word を書く
あるいはゲームをやるための環境なんだが

>>13
VisualStudio

前スレではＭＳのコンパイラは過去に準拠してなかった部分があるらしいという話は出ていた
現在ではざっと調べた限りでは準拠してると謳ってるようなので
問題起こったらMSのせい、でいいと思うが

C89では//コメントとかアウトだよね。

フリー、シェア含めて今一番ガチC言語の規格に沿ったコンパイラって何だろ？
C99用のコンパイラになるのか？

お前ら落ち着けよ
いまどきWindowsでC++じゃなくC？
ありえん

>>18
ゲイツに侵されすぎｗｗｗ

>>9
暗号化PDFを読めるリーダーを使え

エスパーしてみると、最新のFoxitReaderには黒塗りになるバグがある。

>>17
gcc -Wall -ansi -pedantic-errors
かな？C89だけど

C99激しくいらない

C++0x に導入されるような機能は欲しい。
C++0x に導入されないような機能はいらない。

C99って誰が望んだんだ？

C++あがりが望んだんじゃないの

誰もが望んでいたものもそれなりに入ったような気もするが？

望んでいたものの半分以上はC++にあるものの劣化版だったから困る

C99は糞
K&Rの第3版が出ないのが何よりの証拠

望んでいたというか有名どころの拡張を追認しただけというか

C++ との互換性が無いのは致命的だよな。
C で作った関数の中には C++ から呼べない物も・・・なんて嫌だわ。

>>22
-std=c99もつけてあげて

GCCはC99に準拠していない。

>>33
> GCCはC99に準拠していない。

具体的に。

ググレカス

準拠状況が書いてあるとこがあったな。
完全ではなかったのは覚えてる。

つーかC99完全準拠の環境なんてあるのか？現状

Comeau の準拠状況ってどうなんだろうか？

>>37
Intel C++は100％C99標準準拠だよ

C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？

>>40
スレタイ読め

>>41
ビットシフトはなんの役に立つのでしょうか
でぐぐれ

>>40 ビット単位でシフトしたい時に役に立つ

>>42
やっぱりこれテンプレにいれとかないとダメだな

ビットシフトはなんの役に立つのでしょうかでググれ に一致する日本語のページ 約 766 件

>>34
http://gcc.gnu.org/c99status.html

ふと思ったんだが…

各種処理系のヘッダで NULL が以下のように宣言されているのはなぜ?

#if !defined(__cplusplus)
#define NULL ((void *)0)
#else
#if defined(__LP64__)
#define NULL (0L)
#else
#define NULL 0
#endif /* __LP64__ */
#endif /* !__cplusplus */

つか, C でも (void *)にキャストする必要はないと思われるんだが,
(void*)にキャストしておくとなんかご利益あったりする?

int p = NULL; がエラーになる。

NULLを'\0'と間違えて使うような馬鹿を摘発したりとか、型チェックの面でご利益がある。

#if defined(__LP64__)
#define NULL (0L)

これ処理系依存っぽくて鬱陶しいな

処理系自身がそう定義してるのなら
その処理系で大丈夫っつーことだから問題はないだろう

>>50
printf の可変長引数対策じゃないか？

つーかそういう処理系依存を覆い隠すためにヘッダがあるわけで
ヘッダの定義をのぞき見てあれこれ言っても
このスレ的に意味があるのか疑わしい

処理系定義であるポインタのサイズを、NULLの定義の形を借りて記述しているんだよ

ポインタのサイズが型ごとに異なったりする処理系もあるんじゃなかった？

MS-DOSのミディアムモデルやコンパクトモデルが典型的だな

型ごとにというかデータのポインタとコードのポインタのサイズが違う事はあるな
関数ポインタと通常のポインタに互換性がないのはそのため

pimpl パターンとか見てる分には
データ同士だとポインタのサイズはかわらないはずだとは思ってるが、
規格のどこに書いてあるかとかは知らんなあ。

pimplのどこに異種ポインタの変換が介在するのですかね。

スレ違い

変換は関係ないだろう。
構造体/クラスの中身が分からなくても
ポインタのサイズが決まるようじゃないと
pimpl パターンは使えないという話だ。

ただ、組み込み型との間でもサイズが等しいかどうかは分からんね。
これだけだと。

構造体/クラスの宣言(通常はヘッダファイル)があれば型が分かるから
中身見なくてもポインタのサイズは決まると思う

ポインタのサイズって32bitCPUなら4バイト固定だと思ってた

Intel + Windows で 16-bit アプリケーションなら 32-bit CPU でも
2 バイトのポインタが使われたりする
が 32-bit アプリケーションならポインタは 4 バイト固定

要するに CPU 依存でなくコンパイラ依存

void* と int* でサイズが違う処理系があるらしいが見てみたいな

void* (char*) と int* でアドレッシングが違う処理系があると聞いたが、
それの間違いではなくて？

規格ではポインタのサイズはどこまで規定されている？
構造体型を指すポインタのサイズはすべて等しい？

処理系依存ってことはつまり、ユーザープログラムより下にあるコンパイラからアーキテクチャから
すべてひっくるめて依存。データ型についてうるさいアーキテクチャもあるかもしれない。
(タグビットでデータ型を指定するような)

仕様では、6.3.2.3 で、任意のデータ型へのポインタから void * へ、
void * にしたものから元の型へ、という変換は保証されることになっている。
（関数へのポインタに関しては規定がない）

整数と任意のポインタ（関数へのポインタ含む）との変換は、処理系定義。
ポインタを入れることができる整数の型として intptr_t(uintptr_t) が 7.18.1.4 に。

>>66
> 構造体型を指すポインタのサイズはすべて等しい？
少なくとも、これは処理系によらず保証されている。

同サイズの整数型限定だっけ？ ＞整数/ポインタ キャスト
intptr_t はどのポインタと等しいサイズの整数型なんだろう。
それとも、全てのポインタ型のサイズが等しいと保証されているのか？

intptr_tはポインタを格納できればいいのであって、
ポインタと同じ大きさである必要は無いだろう。

>>69-70
(u)intptr_tに変換できるのはvoid*だけ。

int i = 42;
intptr_t p = (void*)&i;
int j = *(int*)(void*)p;

そしてobjectを指すポインタであればどれでも、voidへのポインタに変換後、元に戻せる。
つまり、voidへのポインタのサイズは少なくとも関数ポインタ以外のすべてのポインタ以上。

>>71
70に対する反論になっていない

反論したつもりはないよ。

なるほど。
基本型同士、あるいは基本型と構造体型との間で
ポインタのサイズが違ってても良さそうではあるな。

int *とunsigned int*みたいな、指示先型の符号の有無だけが異なる場合、ポインタのサイズは等しい。

>>74
じゃあ何で一見関係ありそうで全然関係ない話をしたの？

>>77
>>69

>>77
何でアンカー間違えただけでそんなに責められないといけないんですか＞＜

先に「間違えた」と言わないから。

>>79
条件の後出しはやめろと。

いじめが好きな人達が集まるスレ

といいつつ自分の非を棚に挙る人が責められるスレ

>>82-83
それはどのスレでもそう

ふと気になったんだけど
>50の、0Lをかっこでくくる必要あるの？

>>85
#include <stdio.h>

#define HOGE 0L
#define CAT2(a, b) a ## b
#define CAT1(a, b) CAT2(a, b)
#define CAT(a, b) CAT1(a, b)

#define STR2(a) # a
#define STR1(a) STR2(a)
#define STR(a) STR1(a)

int main() {
long double a = CAT(0., HOGE);
printf("%Lf\n", a);
printf("%s\n", STR(CAT(0., HOGE)));
return 0;
}

マクロNULLをトークン連結演算子に投げ込むような状況があるとは思えんが

そういう問題じゃない

あってもこまらないし
あればもしかしたら役に立つかもしれないから

一般的にはある必要はない

あってもこまらないし
あればもしかしたら役に立つかもしれないから
とりあえずつけておけ

超カメレスなんだが >>64
ワードアドレッシングのマシンの場合,
ワードアドレス + オフセット
ここで, ワードアドレス == レジスタサイズ
が, バイトポインタになり得ますが…

可変引数型の関数にいくつ引数が入力されたか、
数える方法はありますか？

標準では、ない

＞93
サンクス

そう言えばさぁ...
左辺がキャストできなくなったのは C89 からで ok ?
int c; (char)c = 1;
みらいやつ

*(char *)&c = 1;ならおｋ
ただしcharは必ず整合するけどもっと大きな型だとむやみなキャストは
境界に整合しなくなるおそれがある

それはキャストはしてるけど、
キャストした後の値に直接代入してる訳じゃないよね。

>>95
というかそれが出来た時期なんかあったのか
どういう処理になるの？

>>95
少なくとも現在より前に制定された規格で、
(type)variable を左辺値として認めたものは一つもない。

たしか、gcc, msvcともにラフなモードではコンパイルとおるけど、
結果が違うようになったと思う。

ああ、C++で(type)が参照型なのは除く。

ちなみにC++だと(char&)c = 1って書ける。

>>98
*(char*)c = 1; と同じになった気がする。
K&R C あたりではできると聞いた事があるような気がするが、
詳しい事は俺は知らん。

K&Rではできた。

Ｃでは符号なし整数をビットシフトすると論理シフト、符号有り整数をビットシフトすると算術シフトになるんですか？

右シフトはそのとおり。
左シフトは論理/算術の区別が無い。

わかりました。
早いレスありがとうございます。

符号あり整数をビットシフトして算術シフトになるかどうかは
C の規格では規定されていない。
ただ、実際問題そういう実装が多いだろうね。

unsignedは論理シフトになる
signedが算術シフトになるかどうかは処理系依存

規格見直したら、負の数を右シフトしたときは結果の値が処理系定義になるって
書いてあった。つまり、算術シフトとも論理シフトとも違う結果が得られてもおかしくない
わけだ。

あと、型が signed でも値が負じゃなければ unsigned と同じ動作って決められてた。

２の補数表現じゃない環境だと
算術シフトにならない実装になってるだろうね。

ただしどうなるかは(規格準拠の処理系なら)マニュアルに明記されていなければならない

明記されていればry

最近レスが無いので、ビットシフトについて質問してもいいですか？

負の数の右シフトが算術シフトになるか論理シフトになるかは処理系依存です。

負の数の左シフトは？

「場合によって未定義」でいいのかな？
http://f4.aaa.livedoor.jp/~pointc/105/No.27873.htm
のNo.27888がわかりやすく解説してくれてる。

>>116
リンク先読んだら、負の数は全部未定義としか読めない。

The behavior is undefined if the right operand is negative,
or greater than or equal to the length in bits of promoted left operand.

それはシフト数の方の話だった。

そろそろビットシフトの質問の出番ですか？

C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？

スレ違い

規格上未定義になってる処理を書いたら例外吐いて止まるコンパイラきぼう

いちいち覚えるの面倒

ベンダーに言え

もしさまざまなマシンでどのように実行されるか知らなければ、
知らないということが自分を守る助けとなるかもしれ ない

　　　　　　　　　　　　　　from K&R

例外吐かれるより警告がうれしいな・・・

エラーでいいよ。
どうせ警告も０にしてるんだし。

俺は信号を見ないけど車は俺をよけて通れよ！
なんて高らかに宣言しなくても・・・

エラーでも警告でもアラーとでもいいけど、
そこで止まられるのは、、ちょっとやだな。

過疎スレ

結構前に、アラーメッセージというのがあったな・・・

アッラーアクバル！

http://pc11.2ch.net/test/read.cgi/tech/1206196600/637
↑
の件なんですが、こういうことに出くわした場合、
コンパイラはどういう風に振舞わなければならないとなってるのでしょうか？
それとも未定義？

>>133
未定義
コンパイラの実装依存です
リンカのオプションでエラーにする設定もおそらくあります

src1.c と src2.c で変数 a の型が違ってたりすると悲惨です

C の仮定義ってファイルまたぐと適用外だっけ？

>>134
未定義と実装依存は違うし、そもそもコンパイラにとっては正しいソース
なので、

> コンパイラはどういう風に振舞わなければならないとなってるのでしょうか？

普通に振舞うだけ。

大抵の環境ではリンカでエラーになるはず。
(そのスレでは、エラーにならないと言い張ってるが。)

>>136
未定義なので実装依存と書けばいいの？
gcc なら警告無し
borland C++ compiler なら警告あり

大抵の環境って何が基準？

VC++2008でも警告無しだな

みんなあんまり適当な事言うなよ？

>>133
あまり知られていないが、これは 「仮定義（tentative definition）」 という仕様。
extern も static もついていない、初期化を伴わないグローバル変数の宣言は 「仮定義」 と見なされる。
対する、extern も static もついていない、初期化を伴うグローバル変数の宣言は 「外部定義（external definition）」 と見なされる。

外部定義は必ず実体定義を伴う。
外部定義が複数あると、二重定義となりエラーとなる。

しかし、仮定義は他に実体定義がなければ実体を定義し、
他に実体定義があれば実体定義を伴わない単なる宣言と見なされる。
複数の仮定義を書いた場合、実体は１つだけ定義され、それらの仮定義は実体を共有する。

つまり、>>133 は仕様。

ちなみにこの仕様は C++ で廃止された。
C++ では仮定義がなくなり、
extern も static もついていない、初期化を伴わないグローバル変数の宣言も
外部定義と見なされ、実体定義を伴う。

このあたりの違いの話は C++ の規格の付録に書いてある。

>>137
> 未定義なので実装依存と書けばいいの？

違う。

未定義は何が起っても文句を言うなと言うこと。
(実行したらＰＣが壊れるような実行ファイルを生成しても規格には違反しない。)

実装依存は何が起るかは環境によって違うけど、環境毎に何が起るかは決まってい
ると言うこと。

>>137, >>139-140
すまん、仮定義のことすっかり忘れてた。

未定義は規格は挙動を定義しないということで、
何が起こっても規格に反しないということではあるが、
処理系独自に挙動を定義することまでを禁止する物でもない。
もちろん、それに頼ったコードは通常移植性が低い訳だが。

処理系依存は処理系ごとに挙動を定義することが求められている。

未規定は未定義と似ているが、
正常なコードの中で挙動がきちんと定められていないものを言う。
関数の引数に書かれた式の評価順とか。

仮定義は初耳でした、勉強になりました
ありがとうございます

うげ、仮定義って翻訳単位跨いでも使えるのか。
知らなかった。

本当に翻訳定義またいで使えたっけ？

規格を見る限り、仮定義があると翻訳単位の一番下に = 0 で初期化された宣言があると見なされるようだ。
複数の翻訳単位がある場合は二重定義になりそう？

>>141-142
処理系依存・実装依存は処理系定義(implementation-defined)だけじゃない。
適当なこと言うなよ。

未定義・未規定・処理系定義
どれも処理系の実装に依存してるだろ。

処理系定義は実装には依存しないだろ。

実装によって挙動が違うことを規格が許している、ことを
実装に依存している、と言うのであって、
処理系定義は実装に依存していると思うが？

処理系定義は仕様としての表明であり、実装とは切り離されている。
具体的なモノとは分けて考えるべきだろう。

JISでは処理系と訳されてるけどimplementation definedだから「実装」だべ

その文脈で
>>147
>どれも処理系の実装に依存してるだろ。
の意味を説明できるのか？

>>147 おおむねこんな意味かい?

処理系定義: 動作も結果も保証しないがどうのような振る舞いを示すかは
処理系が保証しなければならない
未規定: 動作の保証はないし処理系の振る舞いによって何が起るかは
不明
未定義: 何が起っても文句は言えない.
処理系自体も振る舞いを規定する必要はない

そもそもX3010に〜依存って言葉はあるんでしょうか？

>>153
未規定：規格が動作を明示することを求めいていない
例）関数の実引数は、どれから評価してもよいし、明示する必要もない。

ない。
一部の人間が勝手にimplementation definedと混同してるだけ。
>>136とか>>141とか>>142とか

「規格が明確に定義していない」には3種類あって、以下のように定義されている。

・処理系定義（implementation defined）の動作
どう動作するかを実装が選択する。そのプログラムがコンパイルできないというのは許されない。
（この構成概念を使ったプログラムは誤りというわけではない。）
（実装が）何を選んだかは（コンパイラの作者が）文書にしておかなければならない。
規格が合法な動作をいくつか用意していてそこから選ぶことができるかもしれないし、
必要条件をとくに課していないかもしれない。

・未規定（unspecified）の動作
処理系定義の動作に似ている。ただし、どういう動作を選んだかは文書にする必要がない。

・未定義（undefined）の動作
本当に何が起きても不思議はないことを意味する。規格は何の必要条件も課さない。
コンパイルできないかもしれないし、誤った動きをするかもしれないし
（クラッシュしたり黙って誤った結果を出したり）、
あるいはたまたまプログラマの意図したとおりの動きをするかもしれない。


以上、CFAQより抜粋

もうメタ議論くらいしかすることないのな

うん。

>154 >156
ただ、CFAQには「実装依存」を「処理系定義の動作」という意味で使っている場所がある。
正確ではないが、その言葉に出くわして意味を解釈する必要があるときは、そのように読むのが一般的であるかもしれない。

それはimplementation definedの正確でない訳だったりしないの?

一般的な機論において、特に混乱するわけでもないから「〜依存」って
書いてるだけ。後出しで X3010 出してきて混同してるとか言われても、
「また KY 君かよ」としか思えない。

>>161
当たったところ、原文では implementation-defined と書いてあった。
ただそもそも日本語で実装依存といった場合におおよそ何を意味するかという話であるので
（だから正確でないのは承知の上であることは書いた）。

つまり
「実装依存」は場面によって指している物が違うから
implementation definedの訳としては使わないほうがよい。
ということだな。

implementationは普通に訳せば実装という意味だから処理系定義という訳もアレかもしれんがな

「実装依存」そのまんまの意味であるimplementation-dependentはかなり広く使われてるようだが特定の言語に限った話じゃないしね

一般の議論ではよく使われる「依存」だが、このスレでは非推奨の
用語ということにしたほうがよさそうだな。
このスレでは直訳した「実装定義」か、JIS用語の「処理系定義」、
「未規定」、「未定義」を使い分けるということで。

C++ が存在するのに新しい C 言語の仕様を策定するのは、C++ のコンパイラは
実装が難しいからですか?

C++はCの上位集合ではありませんが？

上位集合ではないが、ほとんどの場合ソースを変更する必要がないか、
少し変えれば両方で動くようになる。
C99 のように C++ との互換性に問題を作ってまで新しい仕様を作る
必要はないんじゃないか?

C++なんかどうでもよくね

C99なんて誰も必要としていない

inlineとか変数宣言のブロック先頭縛り廃止とかのC++追随と
vsnprintfにlong longなど有名どころの独自拡張の追認だけにしておけば、
もう少し広まった気がする。

Bjarne 先生に相談しないで仕様を決めてしまったのかな。

スレ違い

構造体の宣言と同時に初期化は有用

C++も0xで対応するんじゃなかったっけ
initializer_listとか

いちいち構造体のタグ名の前に struct を付けないといけないのは面倒くさい。
typedef しなくてもタグ名をそのまま型名として使えるようにしてほしい。

C++でもつかっとけ

コンストラクタはいらないがデストラクタが欲しい。

typedef すればいいから正直あまり困らないな ＞struct

自分へのポインタを持つ構造体宣言するときにちょっと書くワードが多いくらいだろう
大した問題じゃない

というか自分はC++でも typedef struct … しちゃうな、なんとなく気持ち悪くて

自分へのポインタを持つ構造体も、事前に typedef しとけば・・・
って、その typedef を書く必要があるから結局は面倒なんだが。

Cでstruct tagを自動でtypedefしないのは、名前空間の問題にひっかかるからかな？

特に理由はなかったんだろう。
何となく struct を付けた方がいいんじゃね？ と思って仕様を作った。
でも、実際には面倒臭かったので C++ では必須ではなくなった。
それだけのことなんだろう。

名前空間は、新規格で導入しない理由のひとつではあると思う。
構造体（共用体）タグが「通常の識別子」として扱われる改定がされた場合でも、
逆に従来の構造体タグ名前空間のままでtypedefされる改定となった場合でも、
もし過去にそうならないことに因って書かれたコードがあったらコンパイルできなくなる。

どちらでもない新しい名前空間を作るにしても、旧来のコンパイラを改良する手間は
名前空間の管理に手を入れる関係上、それなりの手間が必要になる。
そこまでして導入するほどの問題では絶対にない。と思う。気がする。

structってつけてくれた方が構文解析が楽だから、とかはさすがにないか。

多分そうだと思う。
変数がブロックの先頭でしか宣言できないのも抽象構文木の構造に自然に合うからだと思う。
現在の C から派生した言語はほとんどこういう制限はない。

昔はマシンが非力だったから
少しでも楽にしたかったのかもしれないね。

配列の境界検査をしない、という仕様がまさにそれ

しないと言い切るとこのスレ的には間違ってるか
境界検査をしなくてもよい、だな

C++ の std::vector も境界チェックを行う at と行わない operator[] を用意してるから
非力だったからやらない、というわけではないと思われ。

安全と効率を天秤に掛けて、効率を取る漢らしい言語なんです

[]で境界チェックしないのはCとの互換性のためだろ
未定義動作に互換性もへったくれもない気がするけど

可能な限り、安全は言語でサポートするものではなく
ライブラリでサポートするべき、って感じだな。
最大限の効率を約束する。

>>193
std::vector は C にないから
互換性なんてどうでもいいと思われるが。

VRAM直書きの時、境界検査されたらちょっとヤだな。

論理エラーまでチェックしていたら OS なんて書ける性能はでないよ。

>>195
メモリ配置の連続性要求はCとの互換性のため

>>198
連続性要求と境界チェックは別の話だっしょ。

境界チェックしてほしいなら /RTCs を付ければいいよ。VC 以外は知らない。

>>199
連続性要求と境界チェックは同じだとは言っていない。
「互換性なんてどうでもいい」なら連続性要求も必要ないはずだと言いたいだけ

俺のカンでは話がかみあってないな

>>196
VRAM サイズの配列を宣言して、VRAM のアドレスにマップできるようにすればいいだけ。

>>197
いつの時代だよ。

爺は早めに引退しとけ。

>>201
普通の配列の話じゃなくて std::vector の話なんだけどな。
普通の配列に関しては互換性も理由の１つだろう（それだけじゃないとは思うが）。

>>203
そうやってどんどん OS を重くしてるから
Vista みたいに叩かれるんだよ

>>204
配列じゃなくてstd::vectorに連続性要求があるんだけど

まぁ「レガシーAPIにstd::vector渡せますか？」
というのはC++のFAQだよな

次の規格ではstd::stringもそうなるんだっけ

std::string::c_str() があるのにそんな必要あるの?

現在のc_strはコピーが発生する可能性があってパフォーマンスに響くかもしれない。

どう考えても>193がおかしい
Cにはvectorが存在しないのだから互換性が問題になるはずがない

Cで書かれたライブラリとのバイナリ互換性とか

>>206
だから連続性要求の話なんて誰もやってないんだってば・・・。
境界チェックの話だ。

そもそもだなぁ
なんで std::string::c_str() な話がこのスレで出てくる？

もし境界チェックを行う必要が無いという仕様が
大昔はマシンパワーが弱かったからという問題で作られたのなら
C++ を作る時に std::vector で at でも operator[] でも境界チェックをすれば良かった。
でもそうしなかったということは、それだけの問題じゃないってことだろう。
という話。

だからCもC++も基本的に効率側に仕様を倒すんだよ

安全性はライブラリで頑張る方針

そういうこと。
昔マシンパワーが弱かったからじゃなくて、
マシンパワーに関わらず効率を取るってこった。

マシンパワーが高くなっても 10 分かかっている処理は速い言語で 5 分にしたいよ。
アプリにもよるけど。

>>215
> 効率側に仕様を倒す

ちゃう, 特に C に関しては高級言語だと思ってはいけない

freestanding な環境でも動作可能, つか, 標準ライブラリを使用せず
(libgcc とかは微妙だけど)に動作可能なバイナリを吐き出せる事も
求められている.

実際 crt.o を自前で書けば, 標準ライブラリを使わずに実行イメージを
作ることが可能(しつこいけど libgcc とかは微妙)

境界チェックに関しては微妙だけど...

>>212
だから境界チェックしてない理由(の1つ)に連続性要求と同じ理由は考えられないのかと
言ってるだけなんだが。
std::vectorがCにないから互換性の問題がないなら
operator[]で境界チェックをやることだって互換性の問題を起こさない

>>219
連続性要求は C++98 ではなく C++03 で導入された。

>>203
世の中Cで書いたプログラムのターゲットは3GHzクラスばかりじゃないんだよ。

>193は自分のレスをもう一回冷静に読み直せ
>191はvectorの境界チェックのみの話しかしていない
だからそもそも互換性や連続性の話は関係ない
お前が勝手にoperator[]全般の話を持ち出したから話がかみ合ってないだけだ

これは俺のカンだけど
>>193はoperator[]はあらゆるオブジェクトで同じもんだと思ってるね
でなきゃ互換性なんてセリフ出るはずがない

>>219
vectorの連続性要求の理由はそのほうが直感的かつ便利だからであってCとの互換性からではない。
なぜならvectorはCに存在しないから。C++にしか存在しないものがCとC++の間での互換性で問題になる　は　ず　が　な　い　。

>>224 だったらスレタイ読んで出直してこい

>>225
お前はレスの流れを読むべきだな

>>221
で、それがどうかしたのか？

非常にタイトな部分には、チェックをはずせるようにしとけばいいだけだろ。

しょぼい環境の奴は、頭もしょぼいのか？ (w

仕様と処理系の区別もつかないくらい耄碌してるのか。

「ディフォルトは検査するが、指定した部分の検査をしなくてもいいように指示できる」

と言う言語仕様にすればいいだけ。

どこに処理系の話が出てくるんだ？

# 耄碌爺って他人を耄碌してると思いたがるよな。(w

C言語の仕様は
「チェックなんて効率の悪い事はデフォルトではしない。検査は各々自己責任でやれ」
というスタンスなんだよ

耄碌してんじゃなくて若くて無知なだけだったか。

>>230-231
はぁ？ いまごろ何言ってんの？

そんなこと >>192 に書いてある。

耄碌爺はちょっと前のレスすら覚えてないらしいな。

病院に行った方がいいぞ。

話の整理

197 「Cぐらい男らしい言語じゃないとOSなんて組めないよねー」
　　↑ 偏見というほどでもないがたぶん誇張
203 「そんなことはない、今のマシンのスペックなら（他の言語でも）十分いけるよ」
　　↑ 正しいとは言い切れないが間違いではない
221 「そんな高スペックの環境ばかりじゃないんだよ」
　　↑ ここがずれてる　203はそんな環境でCでない（チェックの厳しい）言語を使えとは言ってない
227 「低スペックな環境なら（その言語の機能で）チェック外すようにできればいいだろ」
　　↑ まあ正論
230 「Cはそういう言語じゃないんだよ」
　　↑ Cでない言語の話をCの話と勘違いしている

というわけで話の理は203にある
だが煽るのはやめろ

自演乙、と言えばいいのか？

すっかり違う言語にかわっちゃうような機能を、オプションでつけはずし？
配列とポインタが交換可能なのはC言語の特徴ですよ。
ポインタが配列を指してるかどうかのチェックからするんですか？

ああ、そうか、>>203は最初からC言語の話なんかしてないのか。
>>233　解説ありがとう。

ということで、スレ違いだな。

C言語は最適化のヒントを与える機能を追加すれば後は拡張しなくていいよ。
C言語の役割はある程度ポータビリティーがあって可能な限り性能を出すこと。
どんなに CPU の性能が上がってもこの需要はなくならない。

できることが増えるスピードよりやりたいことが増えるほうが速いからな

>>235
相変わらず、頭固いネェ。

> 配列とポインタが交換可能なのはC言語の特徴ですよ。

未だに配列アクセスよりポインタアクセスの方が常に速いとか
思ってるんだろうな...。

頭の固い人間 VS 論点がズレている人間
の対決はいつ見ても不毛

>>239
君の脳内言語の話はスレ違いだ。

C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？

>>242
それなんてコピペ？

こんな感じでよろしいか？

おｋ

>>241
反論できなくなったら、脳内言語ときたか。

だったら、>>221 あたりでそう書きゃいいと思うが、
しょせん耄碌爺には無理か。(w

煽るな

>>245
>>233 >>236

>>245
つまりこういう事だな。
「脳内言語だって気が付くのが遅せーんだｙｐ」

昔の知識で煽ったら、反撃くらって撃沈しただけだろ。

俺言語の話なんかする奴が悪いな

俺言語君の知識は、最近のCPUは速いって事だけだったからな。
反論する余地は無いな、たしかに。

お前らも煽るな

大勢のフリした一人だろ。煽っているのは。

おやそくの一言が出ました。

お夜食？

↓　タイプミスをプギャーして勝ち誇るAAをどーぞ

m9（＾д＾）

ぐぐってもプギャーの意味分からなかった。

> 俺言語君の知識は、最近のCPUは速いって事だけだったからな。
> 反論する余地は無いな、たしかに。

にもかかわらず反論してた爺は哀れだな。(w

いつまでも爺爺言ってる奴が根に持ちすぎてて怖い
将来犯罪起こしそうだな

脳内言語だと解ってからは、だれも反論なんかしちゃいないのにな。

>>261
> 脳内言語だと解ってからは、だれも反論なんかしちゃいないのにな。

>> 反論してた

爺は日本語も不自由らしい。(w

俺言語の話してるのに、C言語の話だと思って反論してやんのプギャー
こうですね、よくわかります。

ひっかかった、くやしいムキー。
こうですね、よくわかります。

いつまでやってんの！

ケンカはやめて（＞＜）

爺で検索すればいいからわかりやすいな

C89 との違いのみを完全に全て列挙したような資料ってありますか？

C89 と C99 との違い・・・です。

完全かどうかは知らないけど
http://seclan.dll.jp/c99d/
とか

!0の値は1ですか？不定ですか？

1です

ありがとう

>>270
結構詳しいですが、完全なんですかね・・・。
何か漏れがあるとかいう話はないんでしょうか。

究極的にはC99の規格票買ってきて突き合わせるしかないだろ

意味情報を利用しても、C (C89) の文法はLALR(2)ではないかという
疑問がありますので質問です。

構文規則はK&Rのものしか参照できないので、もしかしたら仕様書の
ものと違うかもしれないのですが、

compound-statement:
　{ declaration-list_opt statement-list_opt }

という構文規則で、

int foo;

typedef int foo; /* 型名とグローバル変数の名前空間は独立 */

void bar(void)
{
　foo ?? /* ?? を読むまで、fooは宣言の一部であるとしてシフトするか、
　　　　　文の一部であるとして、宣言を空にリダイレクションするか、決められない */

と思うのですが、間違いがどこかにありますでしょうか？

>型名とグローバル変数の名前空間は独立
この仮定が間違ってる。

型名も変数名も全て「一般の識別子」だよ
違うのは構造体タグだろ

識別子と言うことと、名前空間の管理は全然別の話だよ。

Cの名前空間は4種類。
・ラベル
・タグ
・メンバ
・その他すべて（typedefした型名や一般の変数の名前を含む）
つまり二つのfooは同じ名前空間を持つ。
これを同じスコープ（この場合ファイルスコープ）で使ったら当然衝突する。
スコープが異なるなら識別子の優先順位と隠蔽によってまったく問題なく処理できる。

Ｃ言語 名前空間 でググルとほとんどどんぴしゃの内容が...

http://uyota.asablo.jp/blog/2006/08/24/497407

>>281
まちがってるなぁ
そこでa a;が許されるのはスコープが違うからであって名前空間が違うからじゃない

グローバルな型名はローカル変数名でシャドウされる？

されるよ。

たとえば、

typedef int a;
a main(){
a a;
a b; // error
return 0;
}

型を宣言するとき
defineではなくtypedefを使わないといけない明確な理由って
なんですか？

今まで普通に使ってきたけど、新人にどう説明すればいいか
悩んでいます。

>>286
typedef char * pchar;
pchar a, b;
sizeof(b)=?

#define pchar char *
pchar a, b;
sizeof(b)=?

>>286
あと、たとえば型size_tを要求する関数があったとして、
#define size_t int
とかやると、size_tの変数を渡してもintで宣言した変数渡しても、コンパイラには区別がつかない。

>>286
typedef char *pchar;
const pchar a;　　　→ a が const

#define pchar char *
const pchar a;　　　→ *a が const

主にポインタ関連で困ったことになる。

>>288
もともとCのtypedefは弱いtypedefだから区別ないけどね

>>286
関数ポインタ形とか配列型だと、構文の都合上で#defineではできないってのもあるね。

defineじゃデバッグ時にこまるじゃん

typedefにはスコープがある。
defineには無い。

typedefにはスープがある。
defineには無い。

define には名前空間がない。

typedefにも名前空間はない

我輩には名前がない。

うちの女房にゃひげがある

さぁみんな、微妙に勘違いする仕事に戻るんだ！

C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？

こうですね、わかります

全てのビットが0のポインタを得るにはどうすればいいでしょうか。
次のようなのを考えましたがなんかイマイチ。

void *p;
p = (void*)(1-1);
p = (void*)!1;
p = (char*)1-1;
memset(&p, 0, sizeof p);

この中では　memset(&p, 0, sizeof p);　が最も確実。
上の2つはもしかしたら上手くいかないかもしれない。
3つ目は明らかに間違い。

いや、3つ目もいいんじゃないか？

一番下以外は未定義動作

こういうのは？
p = (void*)(int)0;

整数をポインタにキャストした場合の動作は定義されない。

>>306 んなこたーない。

ポインタ型は、(何らかの)整数型と情報を失わずに相互変換できる。

別に0というリテラルがヌルポインタとして使えると定義されてるわけじゃないぞ。
コンパイル時に0になると決定できる定数式は全部ヌルポインタとして使える。
だから
p = (void*)(1-1);
p = (void*)!1;
はヌルポインタ。

>>309
だから、NULLポインタは全ビット0とは限らない、って話だろうが

だから上二つは上手くいく保証がないってことだろ

上3つでねーの

memset() の第2引数が定数の0だと本当にビットパターンが0になるの?
bzero() がもともとそういう仕様だから確実じゃない?

>>313
もちろん。関数の引数は常に値渡しだ。
ということは memset() が受け取った値0は必ず変数に代入されて処理される。
変数0がヌルポインタに変換されることは絶対にない。

> void *memset(void *s, int c, size_t n);
> memset() は s で示されるメモリ領域の先頭から n バイトを c で埋める。

man にはこれくらいしか書いていないけど、c が int だと意味が分かりにくい。
一旦 c が char に変換されてから n バイト書き込むということか?

1の補数表現を許しているから
"0"が"+0"や"-0"という場合があって
それで(charにして)埋めた場合にどうか、という話だろうな。

俺は知らん。

>>316
考えにくいけど、もし通常の定数0が-0だったとしても、
ヌル文字が全ビットゼロであることが保証されているから、
少なくとも文字定数\0は全ビット0のはずだね
というわけでmemsetでゼロクリアするときは\0を使おう

なんでわざわざ難しく考えるんだ？
実際、仕事でプログラムを作るときは仕様などを考えることに
時間を割くのに、お前達はコーディングに時間を割きそうだな。

プログラム板で仕様を語ってどうするよ
ここはガチ規格スレだぜ

糞仕様書のせいでコーディングに時間を割かなければいけないことならよくあります。

>>311
違う。
上手くいかない保証があるってことだ。

>>317
通常の整数定数0の全ビットが0であることも保証されていると記憶しているが。

定数の全ビットが0でもメモリに記憶されたときもそうなるの?

>>321
上手くいかない保証って...、なんだそりゃ。

>>323
ならなかったらビット演算で死ねるだろ

メモリ上でどうなっていても演算の結果が正しければいいんだよ。

C で言う所のメモリ上のビット配列ってのは
整数型の変数でビット演算によって参照できる値だっしょ。

C89で、名前は同じで引数の有無や個数が異なるマクロを複数定義することって認められてたっけ？

つまり、
#define A 0
#define A(x) x

前スレで話が出て、できるってことだったような

gcc でエラーになるけど。

>>329
情報�d
前スレ見てきたところ、同じ名前のマクロを同時に複数定義することはできないと書いてあったわ。

>>331
ごめん完璧まちがって記憶してたわ

ここにいる人って、アプリ屋？それともファーム屋？
なんか、話だけを見ると、アプリ屋のほうが多いような気が・・・

>>333 その区別に何の意味がある？区別のしかたもよくわからんしな。

まるでファーム屋が多くて然るべきだと言いたげに読めるのは、俺の日本語力が弱いせいですか？

スレ違いだと思う

ファーム屋(笑)

マ板でやれ

俺はいわゆるファーム屋だが、
アプリ屋＞＞＞＞＞ファーム屋
という印象がある。
はっきりいって、組込みソフト開発者はC言語と少しのハードウェア知識があれば、
あとは、仕様理解で仕事ができる。

様々な新しい技術を吸収し、開発しているアプリ屋のほうが技術は高い。

組み込み系のスレあたりを見てる印象だと、
組み込み屋には実装至上主義で、仕様ナニソレ、という雰囲気がある。

このスレにいるのは、なんちゃってであっても自分で処理系を書いたり
したことがあるような、アプリよりはシステム寄りの人が多いんでは？

そりゃ偏見だ。
アプリ屋だろうがファーム屋だろうが底辺を見ればやっぱり底辺。
上をみればちゃんとしたひとも居る。

ただ、ちゃんとしたアプリ屋がシステム方面に行ってしまうのと同様に
ちゃんとしたファーム屋はハードに行っちゃう事が多い。

最近組み込みは年々ハードが高性能化、開発サイクルの短期化で、
少人数の職人的な開発者での開発は限界に来てますよ

これからはアプリに近い開発方法論でやっていこうという欧米の流れ

>>339
> 様々な新しい技術を吸収し、開発しているアプリ屋のほうが技術は高い。

新しい技術って Ajax とか Web 2.0 とかのこと？

まあ、そう言う新しい言葉を理解するのも技術力のひとつではあるが。

…(^^;;

>様々な新しい技術を吸収し、
訳：新しくリリースされたアプリの使い方を覚えて、

アプリ屋の俺から言わせてもらえば、
　アプリ屋→頭ゆるゆるで使えない奴が多い
　ファーム屋→頭かたすぎて使えない奴が多い

自称技術者の93.2%は使えないから、そんなもんｈだろう。

int a = 3; { int a = a; printf( "%d", a ); }

このとき表示される数字は 3 ですか？それとも不定ですか？
JIS X 3010-1993 を少し読んだんですが分かりませんでした。

>>348
規格を見ずに gcc でテストしてみたところ
2147344384
と出力された

>>349
規格的には不定だよ. {} の中では新たなスコープが有効になるので
{} 内の a が 宣言された瞬間に {} 外の a は shadow される
# 言い方が厳密じゃないんだけど、言いたいこと分かってね

Lisp 系言語の
(let ((a 3)) (let ((a a)) (???? a))) ==> (let ((a 3)) (lambda (a) (??? a)) a)
みたいな物を, 求めてはいけない

>>350
こういうのはOKですか？
int a = 3; { int b = a; int a = b; printf( "a=%d b=%d", a, b ); }

>>351 いや、だから…
言い方が悪かったのかorz
{} 外の名前が {} 内で宣言されたら shadow される

処理系によっては「{} 外の a」が意味をなす場合もあるかも知れないが
可搬なプログラムを書こうと思ったら、その事実に依存してはならない

>>352
規格では変数の宣言順序に関係なく
同一スコープ内で同名の変数が現れた場合には
外側の変数は見えなくなる

だから >>351 は次のようにしないと動作の保証ができないということですね
int a = 3; { int b = a; { int a = b; printf( "a=%d b=%d", a, b ); } }

JIS X 3010-1993 には以下のように書いてあるけどこれからは判断できなかった。

6.1.2.1 識別子の有効範囲
識別子は、有効範囲(scope)と呼ぶプログラムテキストの範囲にあるときだけ、可視(visible)
(すなわち、使用可能)とする。有効範囲は、関数、ファイル、ブロック、及び関数原型の4種類とする。

識別子を宣言する宣言子又は型指定子がブロック内又は関数定義の仮引数宣言子の並びに現れる場合、
その識別子はブロック有効範囲(block scope)をもち、その範囲は対応するブロックを閉じる}によって
終了する。

字句的に同一な識別子のより外側の宣言が同一の名前空間にある場合、外側の宣言は現在の
有効範囲が終了するまで不可視となり、その後再び可視となる。

二つの識別子は、有効範囲が同じ場所で終わる場合、そしてその場合に限り同じ有効範囲を持つ。

そうか？
はっきり書いてあると思うんだが。

>>354 を読んで解釈のひとつとして

int a, *p=&a; // これは OK
int *q=&b, b; // これは NG

ということは有効範囲とは変数の宣言順序によって変化するのではないか？
>>351 の int b=a; の時点ではブロック内で変数 a が未定義であるため
外側の a が可視だから動作が保障されるのでは？

いや、shadowされているが未定義である状態。

>>357
>>354 のこの部分
＞識別子を宣言する宣言子又は型指定子がブロック内又は関数定義の仮引数宣言子の並びに現れる場合、
＞その識別子はブロック有効範囲(block scope)をもち、その範囲は対応するブロックを閉じる}によって
＞終了する。

これは有効範囲の終わりについてのみ言及しており、
変数自体は変数宣言以降から有効になるのではないの？

だからそういっているんだが。

shadow されるのは
１．同一変数名の定義されているブロックの開始部分からなのか
２．それとも同一変数名が宣言された後なのか

というところで ２ で解釈可能では？

ちなみに下記のコードで gcc および Borland C++ Compiler では、警告も無し

// 出力結果は a=2.000000 *p=3 が保障される？
#include<stdio.h>
int main(){
int a=3;

{
int *p=&a;
double a=2.0;
printf("a=%f *p=%d\n", a, *p);
}
return 0;
}

>>360 の
int *p=&a;
の行が規格としては
１．エラーになるべきか
２．未定義（実装依存、鼻から悪魔）か
が知りたいのですが

>>357 さんは ２ ということでしょうか？

>>361 に追記
３．定義済み （>>360 のコードは規格に沿っている）

ISO の、ダウンロードできるドラフトでは >354 が引用した部分の直後にスコープの開始位置に
ついての説明があった。それによると、変数名のスコープが始まるのは変数宣言内の変数名の
直後。

ってことで >351 は OK 。

>>363
ありがとうございます
スッキリしました
これでゆっくり眠れます

真偽値は非ゼロとゼロ、というのは環境依存でしょうか
それとも規格上間違いなく非ゼロが真、ゼロが偽でしょうか

規格上決まってる

>366
ありがとうございます

http://pc11.2ch.net/test/read.cgi/tech/1225320579/951-

int main(){/* ... */}が標準準拠かどうか揉めてます
識者の見解をお願いします

>>368
X 3010：2003 (ISO/IEC 9899：1999)より抜粋
> 5.1.2.2.1 プログラム開始処理　プログラム開始処理において呼び出される関数の名前は，main とする。
> 処理系は，この関数に対して関数原型を宣言しない。この関数は，次の4 種類の方法のいずれかで定義し
> なければならない。
> − 返却値の型int をもち仮引数をもたない関数
> int main(void) { /* ... */ }
> − 二つの仮引数をもつ関数（仮引数は，これらが宣言された関数に対して局所的であるため，どのよう
> な名前を使用してもよいが，ここではargc 及びargv とする。）
> int main(int argc, char * argv[]) { /* ... */ }
> − 上に掲げた二つの方法のいずれかと等価な方法(9)
> − 上に掲げた三つの方法のいずれでもない処理系定義の方法

最後の処理系定義（文書化）が遵守されている処理系において厳密でないほうの規格合致プログラムだな

Cでは基本的に () と (void) は異なるが、
関数定義においては同じとされていたはず。
GCC ではそうなってなかった気はするが・・・。

そもそも組込みには必ずしもmain()はない・・・というのはここでは禁句かな？
しかし、いくらC言語の規格に準拠していても、MISRAに準拠していないと言うことで
プログラムの作りかえをさせられるのはウザイ・・・
逸脱手順を書くのもウザイ・・・

>>368
言いだしっぺです。
int main() が標準準拠かどうか？でもめているのではなく、（そういうことならいうまでもなく標準準拠に決まっています。）
int main(void) を標準としたのは馬鹿じゃないの？ということです。
昔 fj でもめたのを受け売りしただけですね、はい。

>>372
main() は K&R 準拠だろ

>>371
ホスト環境とスタンドなんとか環境ですね

>>372
int main(void) 以外の何を標準にするべきで、そうすると何がうれしいと思ってるの？

>>375
int main(void) は削除するのがいいでしょうね。
int main() という書き方が現在でも有効であるのに、なぜわざわざ int main(void) というセンスのない書き方をまかり通すのか理解に苦しみます。
そのこころは、つhttp://pc11.2ch.net/test/read.cgi/tech/1225320579/962

こちらは将来的に削除される予定
> int main()

>>376
リンクされたスレは既に dat 落ちで見れない。

>>376
センスがないって、どのように？

(void)にセンスがないというのは理解できる。
空の()で引数がないことを表すことにしたC++の英断は素晴らしい。

Cの方は過去のしがらみもあったしな

くだらねぇぇぇぇ

引数チェックのない時代の名残だからな。

>>379
呼び出し側は引数の有無にかかわらず同じだったとしたら、呼び出し側の実際と違う宣言をなんの躊躇もなく記述するところ。

>>384
main の呼び出し側はスタートアップ関数であって、
スタートアップ関数はコンパイラが提供するものだろ・・・。

>>384
呼び出し側の実際の宣言は何だと思っている？

ソースコード側でC言語の管轄外の世界に勝手な仮定置いちゃダメだろ
標準的に考えて

>>387
プログラム開始処理（program startup）が main を呼ぶ事は
5.1.2.2.1 プログラム開始処理 に規定されている。

きっとOSが「いんとめいんかっことじかっこ…」とかコマンド打ち込んでると思ってるんだろう

>>388
プログラム開始処理がmainを呼ぶ時に引数をチェックしないなんて規定されてたっけ

>>390
多分お前の話したい奴は別の奴だ。

スタートアップ処理はコンパイラが用意するから
main がどうなっていようと良きに計らってくれるっしょ。

main関数の定義でint main()と書いてるんだから
引数なし以外ありえない。
関数宣言での引数省略と勘違いしてるんだろうね

>>385
スタートアップ関数は引数の有無にかかわらず同じだったとしたら、スタートアップ側の実際の違う宣言を躊躇なく記述することに疑問を感じています。

>>386
実際のところ、
int main(int argc, char **argv, char **env)
でしょうか。私のところの某処理系では環境変数がコンパイル時スタックをつぶしてしまうので可能なときは再コンパイルしていました。
これってヘッダをさわっただけではどうにもならなかったですよね。

>>387
だから int main() なのでは？

>>389
某処理系のfork()やexec*()の存在くらいは知っています。

>>392
それはそうですね。

>>393
それはそうですね。
コンパイラ側が勝手に stdcall をデフォルトとしている世界であれば、逆に int main(void) でないと困るのかもしれません。
んー ms-pascal？

>>390
プログラム開始処理が main() のために引数を整えている、と理解していますが、実際のところは誰がしているのでしょうか？

>>400
ご明察の通り、スタートアップルーチンがお膳立てします。

osとｃｒｔ

>>376
実は main は関係無くて、引数無しの関数の引数リストが void なのが不満なだけなのか？

不満なら書かなきゃいいだけの話では?

>>394
＞スタートアップ関数は引数の有無にかかわらず同じだったとしたら、

その仮定がおかしい

実際同じじゃね?
呼び出し側で積んだ引き数は、呼ばれた側が無視しても全く問題ないわけだし。

例えばint func() {return 0;}という関数を宣言なしでfunc(0)と呼ぶときと事情は変わらない。

>>402
os? shell ではないのですか？
というか shell と crt との役割分担は？あー ms-dos以外の場合で、てことで。

>>405
ん、たしかに stdcall がデフォルトのコンパイラがあったとしたら、その場合スタートアップ関数は int main(int c, char **v) と int main(void) とでは異なるでしょうね。

>>403
ん、そです。

>>409
すると、>406のようなfuncも気に入らないと。

>>408
>406

>>410
int func(void) {return 0;}と書いておきながら、func(0)と呼ぶのが気に入らないだけなんですが。

>>402
shell の末尾は exec*() でしたね。失礼しました。

>>409
古い（規格化以前？の） C では、引数リストが空の関数宣言は引数の数や個数を指定せずに
関数を宣言するものとなっていた。規格化にあたってそういった過去のコードを不正としないように
配慮した。そういうことだと思う。規格を決めた人が馬鹿だったわけじゃないでしょ。

>>413
そうではなくて、
func() に必要な引数はないけれども、func(0, 1, 2, 3 ... ) と呼び出さざるを得ない状況で
func() の宣言をどうするか？
という問題です。
このとき、int func(void) と宣言するのは、
すっごくやです。

int func(...);

>>415
%gcc test.c
test.c:3 error: ISO C requires a named argument before ...

>>410
＞ >>408
＞ >406
ん？stdcall はreturn時に呼び出され側でスタックを払うから、呼び出し側は呼び出され側の引数を完全無欠に知っておかなければならないかと。

＞すっごくやです。
し ら ね え よ

>>414
> func() に必要な引数はないけれども、func(0, 1, 2, 3 ... ) と呼び出さざるを得ない状況で

>416 のとおり、そういうことはできないことになっている。

>>418
論理的な思考の根源には、ある種の好き嫌いの視点からの判断が含まれることも多々あるのですが、
お気に召さないのであれば、いいなおしましょうか。
「int main(void)は、main() の呼び出し側に思いを馳せていない、という点で、規約としては問題があるかと思います。」

>>419
いいえ、>>416 は、
不定長引数の場合はすくなくとも一つの引数には名前がついていなければならない、と述べているにすぎません。
コンパイル単位が別であれば、
int func(void) { return 0; }
に対して、
func(0, 1, 2, 3, 4, 5, 6, 7)
を呼び出すことは可能です。リンカもエラーは吐きません。

>>420
なら、main(void)用とmain(int argc, char **argv)用のスタートアップルーチンを用意して、
プログラムに合うように選択する処理系があったらint main(void)でも構わないのか？

……自分で書いていて詭弁のガイドラインに抵触するような気がしてきた。

>>421
あるコンパイル単位では int func(int a, ...) と宣言して、別のコンパイル単位で
int func(void) で定義するってこと？

それなら未定義動作だよ。コンパイルできてもリンクできても議論に値しない。

>>423
正確には、あるコンパイル単位では int func(void) と定義しておいて、
別のコンパイル単位から func(0, 1, 2, 3) と呼び出します。
未定義であることの記述があれば教えてください。

というより、cdecl と stdcall の話は処理系依存といえますから、この手の話が規約に載ることもないでしょう。
でも stdcall ならば可変長引数は困難ですし、でも cdecl/stdcall の話が可変長引数に絡むし、そして可変長引数は定義されていますし、
実装によっては不可能な仕様というものでも定義されているのは、どういうことなのでしょうか？

それはそうと、ほとんどのコンパイラでは、スタートアップと main() とのリンクは、上述のようになっているのですが‥‥‥。

>>422
そういうことになります。お目にかかったことはありませんが、完全無欠のstdcall仕様のコンパイラがあれば。

>>424
「別のコンパイル単位」では宣言無しで呼び出すってことか。
どっちにしても未定義動作だけどな。

6.5.2.2 Function calls p6 より
> 6 If the expression that denotes the called function has a type that does not include a
> prototype, ...
(snip)
> If the number of arguments does not equal the number of parameters, the
> behavior is undefined. If the function is defined with a type that includes a prototype, and
> either the prototype ends with an ellipsis (, ...) or the types of the arguments after
> promotion are not compatible with the types of the parameters, the behavior is undefined.


ちなみに、スタートアップと main() とのリンクについては処理系ごとに好きにすればいい話で、
引数リストとかもう関係ない。

>>426
なるほど。
これを見る限り、可変長引数も「実は未定義」なんでしょうか？んー、prnitf() はどうなるのでしょうか？

＞スタートアップと main() とのリンクについては処理系ごとに好きにすればいい話
それでは、なおさら、int main(void) を標準的な記法として盛り込むの問題かと。int main(void) は現実から乖離しています。いらない子です。

>>427
可変長引数は ... を含むプロトタイプ付き関数として定義されている。

main() とのリンク方法が処理系依存でも、処理系に食わせるプログラム自体は
移植性を持つ必要がある。全然関係ない話。

main() の話がしたければ >>375 の質問に対して主観を排除した答えを出せ。

>>428
ん？引用された文章をみると、
> If the function is defined with a type that includes a prototype, and
> either the prototype ends with an ellipsis (, ...) or
(略)
> the behavior is undefined.
だから「... を含むプロトタイプ付き関数」すなわち可変長引数の振る舞いは "undefined" なのでは？

> 処理系に食わせるプログラム自体は移植性を持つ必要がある。
おっしゃる意味がよくわかりません。移植性をもたせることと int main(void) の表記とどのような関係があるのでしょうか？

>主観を排除した
ではhttp://pc11.2ch.net/test/read.cgi/tech/1225320579/962を再掲します。
>> c でよく採用された実装では、呼び出され側のコードは、呼び出し側の引数の個数や種類に依存しない、というもの。....※
>> 個々の関数は翻訳単位を別にとることが可能ですよね。無論、呼び出し側・呼び出され側の引数のチェックがあればそれにこしたことはないのですが。
>> で、main() についても呼び出し側でなんらかの仮定があり、それに対応して main() 記述側で記述するわけです。
>> ※によりmain() 呼び出し側は main() の記述側で必要な引数がどうであれ、常に同じものがリンクされるといっていいと思います。
>> そうであれば、main(void) と書くのは、main() 呼び出し側の仮定と食い違う書き方をしているわけですね。

>主観を排除した
主観がふくまれていたからといって意見として劣るわけではありますまい。そもそも主観・客観ってなんですか？

>そもそも主観・客観ってなんですか？
バカじゃねぇの？

コンパイラは int main(void) を見つけたときと int main(int argc, char* argv[]) を見つけたときで
スタートアップルーチンを自由に変えることが可能。

>>429
君が略した部分を飛ばして読むとそう読めるね。
なんて都合のいい引用の仕方。ふう。

>>427
スレタイ読めないの？
初心者お断りだよ

main() の呼び出しが通常の関数呼び出しと同じだと思いこんでるのが間違いなんだな。

>>429
> 移植性をもたせることと int main(void) の表記とどのような関係があるのでしょうか？

main() の引数リストについて移植性を保証できる表記を定めることに意味があるということ。

スタートアップからの呼び出し方法が自由だからといって main() の引数リストについて
何の規定もおかないでいると、移植性を保証することができない。

そして引数無しと２引数のものが移植性を保証できるものとして選ばれた。引数無しの
ものの記法については >413 のとおり。

>>422
それが本当は正道なはずだな

test

>>434
全くだ。
そこは既にCの規格の範疇外の話だ。

>>431
確かにそのような手はあると思います。完全にstdcall なコンパイラならそうするしかないでしょう。
>> http://pc11.2ch.net/test/read.cgi/tech/1225320579/951
>>399 >>408

>>432
え？ether A or B の B を略しただけですが？
B を略するかしないかで大きく意味が変わる文章なんですか？

>>433
どこが初心者だと感じたのか、詳細を記述いただければ幸いです。

>>435
移植性を保障するためにある一定の枠組みを定めておくところについては同意いたします。しかし、
私見では、
int main(int, char **)
のみで十分と思われるのですが、あえて
int main(void)
を規定した意味については、どう考えておられるのでしょうか。
皆さんと私との意見の違いは、この部分にあると考えておりますので、差し支えなければ教えてください。

stdcall/cdecl あるいは別の呼び出し規約も視野にいれて規定されたのであれば、私としても依存はありません。
>>http://pc11.2ch.net/test/read.cgi/tech/1225320579/951

>>436
確かに同意いたします。
http://pc11.2ch.net/test/read.cgi/tech/1225320579/951

>>438
ん？main() といえども、他の関数と同じ、というのがもともとの心なのでは？
単にスタートアップコードから呼ばれる、というだけで。
＃main() を recursive call するのは、違反でしたっけ？

>>430
つhttp://ja.wikipedia.org/wiki/%E3%83%AB%E3%83%8D%E3%83%BB%E3%83%87%E3%82%AB%E3%83%AB%E3%83%88

>>400
are not compatible with the types of the parameters
を略するなよ。おまえ、構文が読み取れてないだろ。

>>444
再帰しようが、別にそのプログラム中でつじつまが合っていれば問題なかろう。

>>442
引数使わない時にまで引数書くのめんどくせーじゃん。

そもそも何で呼び出し規約が関係するんだよ・・・。
最悪スタートアップルーチンを main によって変えれば済むだけの話じゃん。

>>446
私は、元の引用文を
If 
1) the function is defined with a type that includes a prototype, and
2) either 2.a) the prototype ends with an ellipsis (, ...) 
   or 
          2.b) the types of the arguments after promotion 
               are not compatible with the types of the parameters, 
the behavior is undefined.
と考えましたが間違っているのでしょうか？
差し支えなければ、あなたの解釈を教えてください。

>>449
だからそれはすでに述べられ済み。
http://pc11.2ch.net/test/read.cgi/tech/1225320579/951

>>449
呼び出し規約、具体的には stdcall　と cdecl とではスタックを払うのが呼び出し側か呼び出され側にあるか、という違いがあります。
すなわち、呼び出し側で仮定した引数と呼び出され側で仮定した引数とが異なってもよいか、それとも完全に一致しなければならないか、という違いを意味します。
スタートアップコードが main() を呼ぶときにスタックに積む引数と、main() がスタックに積んであると仮定している引数とが一致しなくてもいいのか、それとも一致しなければならないか、ということです。
stdcall では main() がスタックを払うので、両者は一致しなければなりません。

>>448
その論法でいけば、引数がないときには
int main()
とすれば、もっと楽ではないでしょうか。

どうでもいいけどおまえら２ｃｈのレスをソースにするなよｗｗｗ

一体何を問題に従ってるのかさっぱりわからん

読んでて混乱するから以前の自分の発言を話の前提にしたいならレス番を名前に入れろ

>>451
何度dat落ちしたスレのアドレスを張る気だ

頑張って読んだ

要するにお前の主張は
「int main(void)って書くの気持ち悪い！気持ち悪いよねお前らもそう思うだろ！！」
だな？

じゃあそれに対する答えは
「規格が許してるんだから書きたいやつが書いて何も問題ねえしお前の好みなんか知るかボケ」
だよ

呼び出し規約とか関係ねぇから

>>452
main を見てスタートアップコードを作るんだろ・・・。
何で先にスタートアップコードがあるんだよ。
バカかよ。

voidって空って意味だから、int main(void）って書いて
引数リストが空だってことを明示している方がわかりやすい。
int main()だと、引数リストがvoidなのかdon't careなのか不明確。

int main(void)が気持ち悪いってやつは英語のセンスがないんだろうね

>>453
規格上はそれで問題ない。
関数定義での () は (void) と規格上は等価だから
（関数原型ではもちろん () と (void) は別だが）。
でも、その規格に準拠していないコンパイラがあるから
已む無く (void) をつけているに過ぎない。

>>457
dat落ちしてるなら内容も貼って欲しいよね。

http://pc11.2ch.net/test/read.cgi/tech/1225320579/951
951 名前：デフォルトの名無しさん[sage] 投稿日：2008/11/16(日) 21:46:28
>>949
個人的には、int main(void); という書き方に不満があります。私なら int main(); とします。でも、cdecl でも stdcall でも通用するようにしたいのでしょうけれども。

では採決します。

int main(void)が気持ち悪いと思う人いますか？

気持ち悪くないが C++ やってると面倒くさいとは思う。

>>456
発言したが私であることを特に問題にはしていないのですけれども。

>>457
それはあなたの事情であって私の知ったことではありません。

>>466
単発のレス読んでると何が言いたいかﾜｶﾝﾈってんだよ

>>458
main() に与えられる引数を使用しない場合に int main(void) と特に規定したのはどういう理由だろうか？
という点です。その理由が基本的によくわからない（ある程度の推測はあるにしても）し、普通の関数ではそんなふうには書かないので、
これは問題ではないか、ということを問題にしています。

規格そのものを問題にしている以上、「規格が許しているんだから」は答えにならないのは自明なのですが。

>>468
あなたの理解力不足を人のせいにするのはやめてくれませんか？

>>469
普通の関数でも void 書くだろ・・・。

>>469
ダウト。
普通の関数でも引数リストでhoge(void)って使います。

>>460
いいえ、スタートアップコードがあって、main() がそれにリンクするのです。
スタートアップコードを使い分けるにしても、それは同じこと。
大体スタートアップコードを使い分けているコンパイラがありますか？
そんな処理系は printf() をはじめとする可変長引数の関数が一切使えないのではないかと。

>>469
　　　　　　　　　　,､‐ ''" ￣ ｀`'' ‐- 、
　　　　　　　　／イハ/レ:::/V＼∧ド＼
　　　　　　 ／::＾'´::::::::::::i､::::::::::::::::::::::::::::＼
　　　　　‐'7::::::::::::::::::::::::ハ:ﾊ::|ヽ:::;､::::::::::::丶
　　　　 ／::::::::::::::/!i::/|/　 ! ヾ　ﾘハ:|;!､:::::::l
　　　　/´7::::::::::〃|!/_,,、　　 ,､==､､''`‐ly:::ﾄ
　　　 　 /|;ｨ:::::N,､‐'゛_,,.＼　　 !"r‐､ヽ　 !;Ｋ
　 　 　 　 ! |ﾊﾄ〈 　,r''"゛　 ,　　 ヽﾟ,シ　ﾘｲ)|
　　 　 　 　 　`y't　　　　 ヽ' 　 　,,ｨｧ　 /／　　
　　　　　　　　 ! ぃ､ 　ト─=ニニ‐ノ　〃
　　　　　　　　　｀'' へ｀`'ｰ─‐‐'´,　 .ｲ
　　　　　　　　　　　 　 `i;､　　 　 ／ l
　　　　　　　　 　　 　 　 〉　` ‐ ´ 　 l`ヽ
　　　　　　　　　　　　／　!　 　 　 　 ﾚ' ヽ_
　　　　　　　　　_,､‐7　　 i|　　　　　 i´ 　 l ｀' ‐ ､_
　　　　 ,､-‐''"´　 ﾉ,､-､ /　､,_ ,.､-　{,ﾍ 　 '､_　 　 ｀ヽ､_
　　　／ i　　　 ,､ｲ ∨　l.j__,,､..-‐::-:;」,ハ、　'､｀ ‐､_　　 ,`ヽ
　　/　　l ,､‐'´　/／ ',／!:::::::::;､--ｧ' /　　｀` ‐　　　｀'7゛ 　 ',

int foo(void)なんて喜んで書く人は、悪いけどプログラミングのセンスを疑いますよ
バカにしてるとさえ感じますね
コンパイラや保守者や、Cという言語に対しても

>>472
あなたとは仕事をしたくない

void 書かないと引数書き放題だろ・・・。
バカか、こいつ。

>>461
引数を指定するのに呼び出し側を考慮しないのはどうかと思います。
それに、スタートアップで引数をスタックに積んでいる以上、main（） の場合は do not care のほうが適当かと。

＞英語のセンスが
英語のセンスなど別にどうでもいいです。

>>463
恐縮です。

>>475
アマチュアの方ですか？
CはC++みたく引数までシグネチャーに含んでくれないので、
型チェックはコンパイル頼みになるのです。
引数なしの関数をチェックさせるために(void)って書くんですよ。

まぁあなたみたいに一人でオナニープログラム書いている人には
関係ないでしょうが。

>>473
使い分ける必要のある環境なら
main のあるソースをコンパイルする時に
自動的にそれに対応したスタートアップを追加するか、
あるいはリンカが main によってリンクするスタートアップコードを変えるか、
そういう実装になるはずだろう。

>>471
「普通の関数でも 引数指定部分のvoid は好まない」とは一言ももうしあげておりません。

>>478
まず、int main() { } の () は don't care ではなく void だ。規格上は。

>>478
＞それに、スタートアップで引数をスタックに積んでいる以上、
＞main（） の場合は do not care のほうが適当かと。
ダウト。
引数をスタックに積むとは限らない。
処理系依存。

>>472
言葉が足りませんでしたね。
呼び出し側で引数を指定しているのに、コール先で引数なしとすることはないと思います。
これが呼び出し側：スタートアップ、コール先：main() であっても同じなのではないでしょうか？

>>485
ダウト。
常に呼び出し側で引数を指定しているとは限らない。

>>484
ん、広く範囲をとれば、それはそういうことになるとは思います。確かに引数をスタックに積むとはかぎりらないでしょうね。

型チェックってのは1つ以上の引数を渡した時に、間違った型として扱わないために必要なのであって
もともと引数取らない関数にとってはどうでもいいことです
だいたい引数取らない関数に引数なんか渡したら誰だって間違いと気付きます

ちなみにC++が引数なし関数までシグネチャに含むのはデフォルト引数があるからです

>>483
詳説を希望いたします。

>>485
＞呼び出し側で引数を指定しているのに、
＞コール先で引数なしとすることはないと思います。
ダウト。
それはあなたの思い込み。
言語仕様上そういうことが可能ならば、間違いは必ずおきます。
プロならばそれを回避しようとするのは当然。

>>488
コンパイラは間違いに気づきません。
コンパイラが気づかなかった事により、人間も気づかないかもしれません。
例えば引数の数を変えた時とか。
そもそも引数の数によって引数チェックが必要か必要ないかが変わることこそ気持ち悪い。

>>489
>>462

何度も同じ事を言わせるな。

引数をスタックに積まない実装など見たことがありません
今までに存在したとも思えないし、これから登場することも考えられません
（ネタやお遊びで作った実用性のない環境は知りませんよ）

規格の無意味な汎用性への配慮の産物がint main(void)という醜悪な構文なのです

>>488
＞だいたい引数取らない関数に引数なんか渡したら誰だって間違いと気付きます
んー、コンパイル単位を別にとれば、問題なくコンパイル/リンク可能で、かつ、大概の環境では問題もないのですが。

>>488
＞ちなみにC++が引数なし関数までシグネチャに
＞含むのはデフォルト引数があるからです
ダウト。
C++にはオーバーロードがあるからです。
知ったかすんな

>>492
これは申し訳ない。調べておきます。

>>493
ヒント：ニンテンドーDS

>>493
レジスタ渡しとかも普通にするだろ。

>>491
そもそも間違って渡したから何だというのでしょう
引数に名前は付いてないので関数からは手出しできません
だから何かを壊すことはありません
せいぜい値渡しの無駄なコピーが何回か増えるだけです
型チェックのコストの方が高いという判断はありうることです

なんだか釣りにしか見えなくなってきたな

>>499
やっぱ引数欲しいや、って増やす事だってあるだろ。
その時に変な引数渡されるかもしれない。

>>489
483じゃないが。

X3010:2003の6.7.5.3の中ほど。
> 並びの中の唯一の項目がvoid型で名前の無い仮引数であるという特別な場合、関数が仮引数を持たないことを指定する。
（中略）
> 関数定義の一部である関数宣言子で識別子並びが空の場合、関数が仮引数を持たないことを指定する。
> 関数定義の一部で無い関数宣言子の識別子並びが空の場合、仮引数の個数および型の情報がないことを指定する。

でもこれって、C99なんだよね。C89とか規格書持っていないから俺は分からない。

>>495
オーバーロードはデフォルト引数が導入されてからずっと後にC++に取り込まれました
オーバーロードも理由の一つではありますが、そもそもはデフォルト引数です
そちらこそ知ったかはおやめ下さい

>>499
＞そもそも間違って渡したから何だというのでしょう
間違って"渡さない"場合もあるだろ。
そしたらクラッシュするよ。

＞型チェックのコストの方が高いという判断はありうることです
型チェックのコスト？
コンパイル時だからコストなんてかかんないよ

>>481
純粋な意味でのリンカがオブジェクトファイルを個別にチェックするのはちょっと考えられませんが。
昔の処理系では、生成したオブジェクトのほかスタートアップを陽にリンクするような方法も紹介されていました。(bccとか）

>>499
引数の数が間違っているとリターンがうまくいかないstdcallやpascalのことも忘れないでください。

>>505
なら前者を採用すればいい話だ。

>>504
引数をとらない関数に引数を間違って渡すとはどういう事でしょうか
意味がわかりません

引数を1個とる関数は当然に型チェックが必要ですよ
その1個の引数に間違った型でアクセスしたら大変なことになりますからね
でも引数をとらない関数は、そもそも引数自体にアクセスが出来ないのです
アクセスできない所に何が積まれようと知ったことではないのです

間違えました

>>504
引数をとらない関数に引数を間違って"渡さない"とはどういう事でしょうか
意味がわかりません

>>502
感謝です。
では、特に int main(void) という規約は必要ないことになるのですが、なぜわざわざ int main(void) という書き方を規約としたのでしょうか？
int main(void) を陽に指定する必要はないと思われるのですが。

>>505
int main(void)とint main(int argc, char **argv)でなくて恐縮だが、
VC++などでは、main/wmain/WinMain/wWinMainのどれが定義されているかによって、
リンクするスタートアップルーチンが変わるようになっている。

>>510
int main(void) と等価な書き方も許されるから
int main() も規格合致。

>>508
ばかだなぁ。
int hoge();
は、引数をとらないんじゃなくて、
どんな引数を渡してもいいって意味なんだよ。
わかる？

>>513
それも意味的には違うな。
引数に関して何も関知しないってことだな。
() は (...) とは意味が違う。

>>507
まあそれはそうですが、すでにその話は私のみならず他の方からも指摘されていたりするのです。>>422

>>515
>>422 は >>481 と同じ主張だ。

>>503
＞オーバーロードはデフォルト引数が導入されてからずっと後にC++に取り込まれました
＞オーバーロードも理由の一つではありますが、そもそもはデフォルト引数です
＞そちらこそ知ったかはおやめ下さい
ダウト。
多重定義導入時にマングリングが導入された。

>>511
それは、リンカを制御する上位構造があるから、ではありますね。そのへんは理解しているつもりです。

なんでアホの好みの問題に振り回されてんの？

>>519
暇だからｗ

>>519
何か話題pls.

>>518
＞リンカを制御する上位構造があるから
？

リンカオプションのことか

ん、やっと自らの過ちに気づいたかな？
今頃顔真っ赤かな？

そろそろISOにint main(void)の抹殺を嘆願する署名を集めてもよろしいでしょうか？

どうやらヤツは壮絶に勘違いしてたようだね
>>508のレスが証拠だね

>>525
お断りします
　　　ハハ
　　 (ﾟωﾟ)
　　／　　＼
((⊂ )　 ﾉ＼つ))
　　 (＿⌒ヽ
　　 丶　ﾍ |
εﾆ三 ﾉノ Ｊ

>>525
どうぞどうぞ

>>523
昔はコンパイラとリンカは別だったのですが。
その辺のニュアンスを含めて、「純粋なリンカ」と書きましたが、昔話ですみません。

今も別だろ・・・。

>>530
それは知りませんでした。多謝。

>>510
確かにint main()と書いても規格の意味するところは何も変わらない。

もうだめだ

実質的に一緒でしょう
今時本当にコンパイルしかしないコンパイラなんてごく稀ですよ
明示的にリンクを抑止するオプションでも指定しない限り

>>532
意味する所は変わらんが、
意味を正確に知るには別の箇所（6.7.5.3）も読まないといけないのが面倒だな。

>>534
それはコンパイラがリンカを呼んでるんだよ・・・。

やっとみなさんのおっしゃることがわかりました。
文法の誤解というか、勉強不足のところがありました。
お騒がせして申し訳ありませんでした。

>>534
コンパイラ単品ではあまりないかもしれないけど、
リンカ単品売りはあるよ。

>>518
VC++の場合、コンパイラを介さずともリンカにmainとかWinMainとかを持ったobjを食わすだけで判別する。

関数宣言で仮引数リストが空の場合と関数定義で空の場合で大違いなので
どっちの方を指してるのかちゃんと書き分けておくれ

>>540
お断りします
　　　ハハ
　　 (ﾟωﾟ)
　　／　　＼
((⊂ )　 ﾉ＼つ))
　　 (＿⌒ヽ
　　 丶　ﾍ |
εﾆ三 ﾉノ Ｊ

main は関数原型を書かないから
関数定義に決まってる

そういやC言語ってC++0xみたいなのって進んでるの？

C99 の先は一応議論されてはいるみたいだが、
あまり熱心ではなさそうだ。
C99 でもう C としては十分だろうし・・・。
これ以上追加していくと C++ になりそうだ。

C99でさえなかったことにされてるのにその先なんて…

>>542
書いたらダメなの？

>>542
そうとは限らんよ
http://binary.nahi.to/b2con2006_sato.pdf

まぁ相当変態なケースだけどなｗ

restrict とか [const] とかはやり過ぎだとは思うが
局所変数宣言位置自由とか inline とか
main での return 省略とかは地味に良いんだがなあ・・・。

C99なんかCじゃない
sizeofがコンパイル時に確定しないような変態言語がCを名乗るな

gcc拡張が標準化されればいいや

>>549
ｋｗｓｋ

void f(int n)
{

}

int a[n]; の時の sizeof a が実行時に決まるってだけだ

おっと途中送信
void f(int n)
{
　　char c[n];

}

この2chブラウザあかんわ

>>543
こういう感じらしい。
ttp://www.hi-matic.org/diary/?20081117#17-4

>>547
おもしれーなw

>>553
thx!
むしろint a[n]; ができる方がすげー

alloca みたいなもんだな。
スタック上に確保されるだろうから
大きな値を使われるとオーバーフローするかもな。

馬鹿ばっか

longjmpで抜けた場合には解放される保証がないということから、処理系によってはヒープ上かも

mainを呼ぶWinMainを書いたことがある俺

main = 0x909090C9;

>>561
> longjmpで抜けた場合には解放される保証がない
ここを詳しく

longjmpで抜ければ、普通スタックは巻き戻される。
つまりスタックにallocateしているなら、解放される。

mallocしたメモリと同じようにヒープに確保して、
暗黙のうちに関数のエピローグでfreeしているとすると
longjmpで抜けてしまうと関数のエピローグを通らないから
freeされない。つまり、解放される保証がない。

保証が無いってのが微妙な表現だな。
スタック使っても、ヒープ使っても、
サイズによってどっち使うか決めても規格合致ってことか。

>>564
longjmpのところに↓のようなことが書かれてる

EXAMPLE The longjmp function that returns control back to the point of the setjmp invocation
might cause memory associated with a variable length array object to be squandered.
#include <setjmp.h>
jmp_buf buf;
void g(int n);
void h(int n);
int n = 6;
void f(void)
{
int x[n]; // OK, f is not terminated.
setjmp(buf);
g(n);
}
void g(int n)
{
int a[n]; // a may remain allocated.
h(n);
}
void h(int n)
{
int b[n]; // b may remain allocated.
longjmp(buf,2); // might cause memory loss.
}

なるほど。may に might か。
開放される実装になってても規格違反ってわけじゃないのね。

関係ないけど、そのsetjmpの使い方、未定義ですな

知らんがな(´・ω・`)

setjmpは条件式の中からしか呼べないんだっけ？

なんだ？ そのわけわかめな制限は。

setjmp の使い方を考えれば至極妥当だと思うが・・・。
無限ループになるぜ。

無限ループになるかどうかも未定義か

An invocation of the setjmp macro shall appear only in one of the following contexts:
- the entire controlling expression of a selection or iteration statement;
- one operand of a relational or equality operator with the other operand an integer
constant expression, with the resulting expression being the entire controlling
expression of a selection or iteration statement;
- the operand of a unary ! operator with the resulting expression being the entire
controlling expression of a selection or iteration statement; or
- the entire expression of an expression statement (possibly cast to void).
If the invocation appears in any other context, the behavior is undefined.

・・・だそうだ

環境限界　setjmp マクロの呼出しは，次に示すいずれかの文脈にしか現れてはならない。

・選択文又は繰返し文の制御式全体
・他方のオペランドが整数定数式である関係演算子又は等価演算子の一方のオペランド。
　この場合，関係演算子又は等価演算子による式は，選択文又は繰返し文の制御式全体でなければならない。
・単項 ! 演算子のオペランド。この場合，単項 ! 演算子による式は，選択文又は繰返し文の制御式全体でなければならない。
・式文の式全体（void にキャストされていてもよい。）。
　setjmp マクロの呼出しがこれ以外の文脈に現れた場合，その動作は，未定義とする。

要するに、
・「if(A)」「switch(A)」「while(A)」「for(X;A;Y)」のどれかのAの場所に、
「setjmp(buf)」「setjmp(buf) op Z」「Z op setjmp(buf)」「!setjmp(buf)」（opは> < >= <= == !=のどれか）
のいずれかの形で出てくるか
・単に「setjmp(buf);」「(void)setjmp(buf);」の形で出てくるか

どっちかでないと鼻から悪魔

なら別にそのまま使ってもいいのか。

制御文の中で直接真偽判定する以外にその値を使ってはいけないってことかな

longjumpから帰ってきたかどうかを示す値が揮発性だってこと？

sequence point間に単独で置いとけってことだろう。

関連の規約をチェックしました。>>537 は実は別人ですが、同じ気持ちです。感謝です。
>>502, >>535 ポインタを紹介していただきありがとうございました。非常に勉強になりました。
なお、>>508 は私ではありません。

久しぶりに覗いてみたら、かつてのfj.lang.cなみのマジキチぶりにワロタ

>>582
それは賛辞に取られかれない危険な発言かと。

fj.lang.cってどこのサイトですか？

>>584
http://ja.wikipedia.org/wiki/Fj_(%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97)

>>585
トン。
理解力ないんでよくわかんなかったｗ
スレタイよくみたら初心者お断りなので帰ります。。。λ

>>584
マジレスするとネットニュース。
Webからアクセスできるゲートウェイも存在するが、
「どこのサイト？」とか言っちゃうあたり時代はかわったんだなぁと思った。

俺は>>584ネタかと思ったよ

俺はパソコン通信からやってるけど
本格的にインターネットを使いだしたのが
遅かったので知らない。

■
■
■■■■■■

■■■■■■■■■■■

>>589
まだナツメネットとかアスキーNETとかｗ

■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
２ちゃんねるという馬鹿な掲示板を削除してくでさい
ドコモ規制するとか頭おかしいんじゃねーの？

のんたん
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■
■■■■■■■■■

　　　 　 __　　　　　,.-､
.　 　 　 l _ヽ 　 　 .l ri.ヽ
　　　　 l l ヽヽ.　 //　l. !
　　　　 l l,.- '　￣　￣　! .,
.　 　 　 l　 rn 　,.、 ｎ　,.ｲ,.-　　　＿
　　　 二l- `'' ヽﾆﾉ-　_,ﾌー‐　 r ,.-- '
.　　　 -‐`ーr'´　〉 ´ 　､ ｀ヽ　,! l
　　 　 　 　 ヽ-r'　　　　 ヽ' ノ /
　　　　　　　　　ヽ、 　 　 　.l' ´
　　　　　　　　　 /´　 /　　 !
　　　　　　　　 ⊂.＿,.! 　 _/
　　　　　　　　　　　　 ￣

ご冥福をお祈りします

あげ

a.cでint iというグローバル変数を定義して
b.cでint iという同名のグローバル変数を定義しても
多重定義にならないのは何故ですか？

>>597
>>133-

>>598
ありがとうございます。

http://d.hatena.ne.jp/ku-ma-me/20081017/p1
これってどうなの？

>>600
似たような話で、規格にはプログラムのサイズについて規定は無いが、実際には有限だ。

関数定義が CPU インストラクションの列で実装されていれば、対象環境の
プログラム配置領域サイズによって制限を受ける。

同じように、自動記憶域がスタックで実装されていれば、対象環境でのスタックの
サイズに応じてプログラムが制限を受ける。

そういうことだと思う。つまりは、言語の規格は上記のような制限の無い仮想マシンに
ついての動作を規定するもので、実装方法や実際の動作環境によって生じる制限には
関知しない、と。

現実のコンピュータでCの規格に完全準拠することは理論上不可能
ってことでいいのか。ありがとう、すっきりした。

理論上はそうなってしまうので、規格には最低限満たして欲しい基準が補足で書かれてる

>>603
どこ？

処理系限界が下限に限らず存在することが規定されている

>>602
ブログの人はそういってるけど 601 は違うといってるんだが。

>>606
じゃあ理論上可能なの？

Cでは基本的に「ハードウェアのやることはなんでもあり」であって、
規格はハードウェアに発する命令の体系を既定しているに過ぎない。
ハードウェアの能力が足りなくて要求を実現できないのと、
実装が規格に準拠しているかどうかはまったく別の問題。

>>607
601 を読んだうえで、不可能だと思う理由を述べてください。

>>604
AnnexB

>>608
メモリ無限の仮想マシンの上で動くバイナリを出力するコンパイラなら
理論上は作れる。実行はできないが。
ってこと？ そういうことなら納得。

>>610
Annex BはLibrary summaryになってる。
手元にC99のCommittee Draftしかないんだけど。

>>611
いや、言語として規定はないから作れる。実行も出来る。
ただ実行した時の結果・挙動についてまでは保証しませんよってこと。

C言語としてはこの場合、「無限再帰呼び出しを行うマシンコードが生成される」
ところまでしか保証しない（コンパイラによっては警告出すかもしらんが）。
それを実行した結果、何が起こるかかまでは規定できないし、しない。

int *p = 0; *p = 100;
このコードがコンパイル出来ますか？実行出来ますか？
って問題と同じだろう。コンパイルも実行も可能だが、結果は環境に依存する。

末尾再帰だからループに直すのだ！

>>612
> int *p = 0; *p = 100;
これは未定義だってはっきりしてるじゃん。別の話。

int *p = 0; *p = (int*)100;じゃないとコンパイル通らなくないか？

>>615 試してから書けよ。

ごめんポインタ2つ宣言してるように見えてた

>>611
その理解であってると思う。極端な話、現実のCPUやOSは物理的に故障する可能性が
あるのに、その上でC言語の仕様に完全に準拠するなんて不可能だ。

>>612
コンパイラの仕事は、入力したソースコードの意味と同じ意味を持つ実行ファイルを
出力すること。実行ファイルの意味はCPUやOSの仕様が規定している。CPUやOSが自身の
仕様通りに動くときは「実行した時の結果・挙動」を保証しないと、「C言語の仕様に
準拠したコンパイラ」とは言えない。

ってか、C言語の仕様は実現方法を規定しないから、「無限再帰呼び出しを行うマシン
コードが生成される」ことも保証されないぞ。

setbuf, setvbuf 関数で自らバッファをmallocして設定したとき、fcloseしたらそのバッファもfreeされるのでしょうか？
もしくはそのバッファは（gccでは）どういう運命をたどるのでしょうか。

RTFM

>>619
glibcだとユーザーが定義したバッファは開放されないみたい。

>>621
ありがとうございます。
linux manをみても、NULLの場合は開放とあるのですがユーザ設定のときは言及もなく未定義とも書いてなかったので。

ユーザがセットしたバッファがfreeして良い(すなわち、mallocされている)のか、
静的に確保されたメモリ領域など、freeしてはならないのかは、
fcloseには分らないから、fcloseの実装でユーザがセットしたバッファを
freeすることはあり得ない。

>>619
フツーに考えたら、freeされないと思う。
根拠はオレ。

仕様的には実装におまかせのはず。

複数行マクロを書くときの体裁なんですが、
伝統的なdo{}while(0)ではなくvoidキャストを使うというのを見かけました
たとえばこんなんです

#define macro() { /* 処理 */; }(void)0

確かにこれでうまくいきそうに見えるのですが、本当の本当に大丈夫でしょうか

>>625
if(hoge)macro();else foo;
でアウツだろ。

なるほど

#define macro() if(1){ /* 処理 */; }(void)0

なら大丈夫ですか？

違うか

#define macro() if(1){ /* 処理 */; }else (void)0

か

問題は無いと思う。
まあ、そこまでするなら do { } while(0) の方がシンプルでいいと思うが。
これの問題は条件式が定数式の場合に警告吐くコンパイラがあるという点だが、
それが解決されてるわけでもないしね。

>>628 にはまだこの問題があるようだ。
macro(), foo();　/* foo() は実行されない */

それはdo〜whileでも駄目なのでは？

do〜whileはコンパイルエラーになってくれる
628はコンパイル通って実行しないからタチが悪い

#define macro() { /* 処理 */; }
だけではだめなんですか？

if (hoge)
　macro();　/* ← 使う側はどういう定義になっているか知らないのでセミコロンをつけて書いちゃった */
else
　foo();

で文法エラーになる。
常に if に { } を付けるスタイルなら問題は無いが。

なるほど。

ともあれこのスレは、Cのイディオムについて語り合うスレではないな。

>>636
誰がそんなこと決めた

文法エラーではじかれるならまだOKですね。
変に動いて誤作動するよりは。

基本ifには{}をつけるので
#define macro() { /* 処理 */; }
でも問題ないですが、これだとMISRA-Cに怒られる・・・

inline macro() { /* 処理 */; }
が一番だな

inlineの基準はコンパイラによって違うそうですが、たとえばgccではインラインされるかどうかのある程度基準（仕様）があるんですか？

inlineじゃなくて、static宣言された関数では？

>>641
C99でinlineが入ったんだよ。

inlineとstaticは同じ基準でインライン展開されるんですか。

よーわからんけど、extern inline が使えるってこと？

>>643
コンパイラ次第。
最適化レベルによって基準に差が出たり出なかったりする、なんてこともある。

>>644
inline 関数は常に内部リンケージ。

最適化をしない設定ではinlineをしていしても無効になるコンパイラもあるしね。

極端な話、今時inlineなんてregster程度の意味しかないと言ってもいい。

register
　・ C ではアドレスを取るとエラーになる（C++ では問題ない）
　・ レジスタにするかどうかは 100% 無視される
inline
　・ 最適化なしでは static 関数も inline 関数もインライン化されない
　・ 最適化低では inline 関数はインライン化されるが static 関数はインライン化されない
　・ 最適化高では static 関数も inline 関数もインライン化される

VC++ ではこんな感じだったと思う。
分岐する最適化レベルがいくらだったかは忘れた。

>>649
ありがとうござます。
inlineはコンパイラによってインライン展開するかどうかは任意だと聞いてたんですけど、最適化を協力にすると任意じゃなくて必ず展開されるんですか
それと、static関数は必ずインライン展開されるんですか。困った話ですね。

ということは、インラインとしては展開できない関数はないですね（つまり必ずマクロ関数みたくなる）。
inlineは最適化から出てきた機能ですが（関数専用の）テンプレートに近くなっているということでしょうか。

>>650
いやいや、必ず展開されるという意味で書いたわけじゃない。
「インライン化されない」と書いた部分は「必ずインライン化されない」が、
「インライン化される」と書いた部分は「インライン化される可能性がある」の意味で書いた。

今のハードなら展開されようが、されまいがどうでもいいんじゃないの。
関数呼び出しコストなんて測定できないような時間（ナノ秒単位）で、普通は参照渡し。
組み込みとかセットボックスみたいだとハード資源が限られてるからループ内部とかでやれば多少効果はあるかもしれない。

画像処理とか激しいループは未だにあるもんだ。

インライン展開することによる最適化も期待できるから
>>652 は世間知らずだな としか思えない。

static以外の関数でも最適化を上げればインライン展開されると思うよ。
外部リンケージ用に、通常関数版も用意されるはずだけど。

まあそこらへんは規格に反しない限りはコンパイラが自由にやっていいことだからなぁ

ファイルのリンケージを考えれば、どっちでもいいということですね。
オブジェクトファイルのサイズが増えても今のハード（携帯なども含む）なら微々たる物でしょうし。
気にしているのは、DLLみたく他人がつかうとき、それが関数のつもりがマクロみたく展開されてると不都合が生じるってことです。
関数ポインタのときとか。

>>657
> 気にしているのは、DLLみたく他人がつかうとき、それが関数のつもりが
> マクロみたく展開されてると不都合が生じるってことです。
> 関数ポインタのときとか。

意味わからん、inline の意味わかってるのか？

実行時の関数呼び出しとコンパイル時のインライン展開の違いはわかってる？

inline 関数の中に malloc があったとき
どっち側でメモリが確保されるのかは気にはなる。

何側と何側の話をしているんだ

DLL側とDLLを使用している側

説明する気もうせる

スレチだしな

いいぞもっとやれ

>>658-659

inline void func();

これを(*func)と関数ポインタで使うときどうなるんでしょうか？
例えばqsortに渡したりするときも、qsortみたいな関数ポインタを受け付けるAPIは実行時評価が目的の設計なので、
インライン展開されると不都合な気がするんですけど。

static関数もファイルスコープにおいて展開されるのは初耳だったんですけど、同じように実行時に不都合がありませんか？

memcmp、strcmp、strncmpの返値だけど

The memcmp function returns an integer greater than, equal to, or less than zero,
accordingly as the object pointed to by s1 is greater than, equal to, or less than the object
pointed to by s2.

これはつまり、a > b > c だとしても、
memcmp(a, b, n)で100を返し、memcmp(a, c, n) で1を返してもいいんですよね？
0より大きいか小さいかだけが問題で。
accordinglyってのは、「大きい小さい等しい」に従うだけで
数値に従う必要はないですよね？

うん。

>>666
上で誰かが書いていたと思うけど、必要なら普通の関数のコードも併せて作るだけ。

>>669
私だよん。

>>666
たまにはアセンブリ出力を眺めてみるもんだよ。
個々の行の意味が判らなくても、全体のボリュームとシンボルの位置でいろんなことが見えてくる。

>>667
その通り。実際、1,0,-1しか返さない処理系もあった筈だし、
最初に不一致だったバイトの差分を返す処理系もあった筈。

ctype.h の関数を手持ちの char について使いたいときは、 char が符号付の場合を考慮して
unsigned char にキャストしないといけないことを理解しました。

でも toupper() の戻り値 int は引数と同じ範囲の値を取るので、そのまま char に戻すことが
できないように思います。

たとえば char 型の変数 c について、以下の条件をすべて満たすとき。
- (unsigned char)c == UCHAR_MAX
- UCHAR_MAX > CHAR_MAX
- toupper(UCHAR_MAX) == UCHAR_MAX ※変換なし
c = toupper((unsigned char)c) という式は char には収まらない UCHAR_MAX を
char に変換することになり、符号付整数のオーバーフローにより未定義動作と
なってしまいそうです。

任意の char 型の値を大文字に変換して結果を char 型で得る方法として、
未定義動作も実装依存も回避した移植性のある方法はあるのでしょうか？

現実的には黙って char に変換すればいいように実装されてることが期待できるとは
思うのですが、ちょっと気持ち悪いです。

なんか、とても杞憂な気がするるが、神経質にするならこうか？

c= isalpha((unsigned char) c) ? toupper((unsigned char)c) : c;

気になってるのは、大文字アルファベットの表現がsinged charで負値になる環境とかだよね。

全く規格確認してないが、intの戻り値retについて、
CHAR_MINが負値でretがCHAR_MAXを超える場合、
自力でunsigned charをcharに変換するコードを書けば
とりあえず解決するんじゃね？

1バイト文字の英数がASCIIで無い処理系ってあんま想定したこと無いから分からないけども、
「ASCIIじゃなきゃダメ」って記述は規格には無かった気がするなぁ。
詳しい人フォローよろしく。

fgetc() なんかも同じだよね。とりあえず EOF をチェックして、それが済んだら char として
扱いたいんだけど、変換できるの？っていう。

>>671
そもそも規格上は unsigned char を signed long するだけでだめなケースがあるから

> 未定義動作も実装依存も回避した移植性のある方法はあるのでしょうか？

の答えは「ない」だよ。

>>673
> 「ASCIIじゃなきゃダメ」って記述は規格には無かった気がするなぁ。

汎用機用の C言語処理系で文字コードが EBCDIC のものがある。

>>671
toupper に正しく小文字を与えれば、正しく大文字になるでしょ？
それ以上のものはないよ

UCHAR_MAXを toupper に与えたらUCHAR_MAXが返るだろうけど、
そもそもなんでその結果を signed char にキャストするの？
UCHAR_MAXを与えるということは signed char じゃなかったんでしょ？

>>674
toupper()やfgetc()の結果をcharと比較したい場合、
charに変換して戻すんじゃなくて、比較先をintにするのが普通では？

　int c = fgetc();
　if ( c == 'a' ){
　　　…
とか

>676
明示的に UCHAR_MAX を与えるわけじゃなくて、unsigned char に変換すると UCHAR_MAX になる値が
char としてあった場合に、unsigned char にキャストしてから toupper に与えた場合とか。

> toupper()やfgetc()の結果をcharと比較したい場合、
比較ならいいけど、char に代入したくなったらどうするの？
例えば、文字列中の小文字を全て大文字に変換する関数 strupper(char*) を定義しようとかいう場合。
やっぱ >672 のように書けってことだろうか。

>>676
> toupper()やfgetc()の結果をcharと比較したい場合、

単純比較なんて誰も悩んでないと思うが。
配列に入れて、printf() で出力したい時とか考えつかないわけ？

signed char が -127〜127 で文字コードが 0〜255 の環境なら、
処理系は char を unsigned char 固定で扱うようになっているんじゃないのか？
じゃないと char が文字コードを収める事ができるという
最低条件をクリアできないじゃん。

>>677
>>unsigned char にキャストしてから toupper に与えた場合とか。

だから、なんでキャストするの？

入力が signed char なら　signed char → int に変換されても
UCHAR_MAX はありえない。

入力が unsigned char なら UCHAR_MAX はありうるけど、それは
変換前も変換後も UCHAR_MAX のままでしょ

>>680
ふふ、

一連のレスで、UCHAR_MAX は一例だと思うよ。
問題は、signed charで表せないのにunsigned charで表せる文字
ではなくて、signed charで負の値になるunsigned charの文字
ではなかろうか。このような文字を安全に
unsigned char から signed charに変換する標準的な方法が無いこと。

もう一つは、toupperの引数は非負が仮定されているので、
toupperの引数は(intだけど)数値としては実質的にunsigned char
を渡す事になる。

この二つの問題が絡み合っているのね。

>680
unsigned char 範囲の値を渡せって規格で要求されてるから。
> 9899:1999 7.4
> The header <ctype.h> declares several functions useful for classifying and mapping
> characters. In all cases the argument is an int, the value of which shall be
> representable as an unsigned char or shall equal the value of the macro EOF. If the
> argument has any other value, the behavior is undefined.

>>683
その文章は知ってるよ。
でもそれは toupper の引数は unsigned char でキャストしろ、って意味.じゃない
signed char を指定した場合で -2 〜 -128 の場合は undefined だよ、って言ってるだけ
(EOFが-1として)

実際死ぬケースもあったな。マイナス与えると。
日本語扱うとよくある。

> 未定義動作も実装依存も回避した移植性のある方法はあるのでしょうか？
最初っから全部unsigned charにしとけでイナフ

>>679 についてはどうなんだ？

>>684
未定義動作を回避するのに、 unsigned char にキャストするほかにどうすんの？

>>679
basic character set に無い処理系依存の拡張文字の char としての値について、
符号も含めて規定は無いから、負の値が拡張文字に対応しても問題なさそう。

6.2.5 Types p3
> An object declared as type char is large enough to store any member of the basic
> execution character set. If a member of the basic execution character set is stored in a
> char object, its value is guaranteed to be nonnegative. If any other character is stored in
> a char object, the resulting value is implementation-defined but shall be within the range
> of values that can be represented in that type.

>684
じゃ、
> signed char を指定した場合で -2 〜 -128 の場合
はどうすれば？
範囲チェックして toupper には渡すなって主張？

>687
0〜255 だというなら確かにそうかもね。
> 9899:1999 6.2.5/3
> If a member of the basic execution character set is stored in a
> char object, its value is guaranteed to be positive. If any other character is stored in a
> char object, the resulting value is implementation-defined but shall be within the range
> of values that can be represented in that type.
という記述を見ると basic execution character set 以外なら負値も認めているように読めるけど、
後は実装依存の闇の中、かな。

int toupper(int c);

なるほど・・・。
完全に環境無依存のコードは無理っぽいね。

卓上の妄想なら不可能だが、現実的にはみんなやってるだろ

なんで文字を扱ってるのに符号を気にしなきゃいけないんだよＣ言語のバカ！

char の符号が未規定なのって
どんなケースを想定してのことなのだろうか。
符号つきの文字コードがあったらいけないから？

8 bit 符号付でも ASCII の表現には十分だから実装任せで良いよね。
っていう話だと思う。

C++ では char を受けて char を返す toupper/tolower があるから、今さら
規格を変更する（変更を検討する）モチベーションも無いだろうしなぁ。

リアルタイムの人間じゃないけど。
規格がまとまる前にsigned, unsigned両方の実装が出ていたから、
というのが最大の理由だったと思う。
そこから先は>>696のとおり。

int は、ディフォルトで signed なのに、char のディフォルトを決めなかったのが
敗因だと思う。

まあ今時だとメモリも潤沢だからわざわざ char に詰め込もうなんて思わないけど、
当時だと short short int の役目もあったのかもしれないな。

MS-ｃがオプションでcharをアンサインドにできる仕様だったからねぇ。
intとは事情が違うね。

lattice-c(2のころ)はunsignedだったっけ？

>>688
出力を未定義にしたくないなら、未定義にならない引数を与えろってこと。
toupper呼ぶ前に、入力文字の範囲チェックしないってことは無いだろう普通

それを unsigned char へのキャストで済ませられたらいいな、と
考えたのだろうけどそれじゃダメって話

>>701
範囲をどうチェックするするべきだと言うの？
チェックで範囲外だとわかったらどうしろっていうの？
toupper() に渡さないと大文字にできんのだが。

馬鹿なの？
大文字にしたければ小文字を渡せよ
if( isascii(c) && islower(c)) c = toupper(c);

これを
c = toupper((unsigned char)c);
とすると規格上不定になります（；＿；）とか言ってるから
キャストするからだろ馬鹿、って言ってるんだ

大馬鹿なの？ toupper の前に islower なんかいらねーよ

>>703
標準の範囲で実装依存せずにどうするかって話なのに、
非標準の isascii() とか入れてみたり勝手に ASCII 大文字だけに要求を絞ったり、
ギャグでやってるのか？

いいえ、ボールギャグです。

で、実際のところa-z|A-Zが符号付き表現で負になることはありえるの？

それは知らないけど、
"C" locale以外ではa-z|A-Z以外でもislower/isupperが真になるということなら有り得ると思う。

真になるってどういう事だよ。

あ、空目してた。ごめんよ。

結局は>>686

>>707
そいつらは basic execution character set に入ってるから char 型の符号の有無に
かかわらず負にならないことが保証されてる。 （ >689,690 が引用してる箇所参照）

>>712
素朴な疑問、EBCDIC な文字コードの処理系の場合どうなるんだ？

>>713 文字コードは関係ない。（ >689,690 が引用してる箇所参照）

>>714
EBCDIC って 8bit だと MSB たってんじゃん, char 9bit 以上で実装しろって話？

>>699
MS-C はシフトJIS でトラブル奴が多いからそういうオプションを
サポートしただけだろ。

>>715 EBCDIC のコードを 8 bit char の値に使うなら char 型を unsigned にするしかないということ。

>>717
fgetsやprintfやstrcmpなどの型も全部変更するの?

>>718
きっと何か勘違いしてると思うけどそれらの関数でどういう問題が起きると思うの？

>>718
unsigned charにするんじゃなくて、
char自体を符号無しにするってことだろ。

>>717 ああ、それなら納得
「>>712 char 型の符号の有無にかかわらず負にならない」
てな、書き方はやめてほしかった

今現在、charをsignedで使う意味ってあるのかな。

>>722
charを文字ではなく数値として使うこと考えれば。
intへの昇格も考えなきゃならんし。

Ｃ言語なら俺に聞け（入門篇） Part 45
http://pc11.2ch.net/test/read.cgi/tech/1235044065/l50

こっちが埋まったんで、とりあえずageておく。

あのグダグダを持ち込まれても困るんだが

ネタ切れ？　じゃぁ

問題：

int i, j;

int main()
{
i = 1;
j = i++ * i++;
printf("%d, %d\n", i, j);
}

このプログラムを実行するとどうなるか？　どうなるべきか？　結果もしくは挙動を推測せよ。
（includeとかmainの型なんかは、適宜補え。文句言うな）

jの右辺が未定義動作だから何が起こるかわからない

「3,6」と表示されるかもしれないし「3,9」と表示されるかもしれないし
「5196823, -98600289」と表示されるかもしれないし「ｑあｗせｄｒｆｔｇｙふじこｌｐ；」と表示されるかもしれないし
プログラムが異常終了するかもしれないしOSがクラッシュするかもしれないし
PCが火を噴くかもしれないし地球が爆発するかもしれないし鼻から悪魔が出てくるかもしれない

常識だと思うが、今更どうした

mainが値を返してないからコンパイルできない

C99なら可だが

鼻から悪魔は無いな、たぶん。

出てきてからじゃ遅いんだよ、出てきてからじゃ。

ネタ切れ？　じゃぁ

問題：

int a[32], b[32], *p = a;
if (p < b || b + 32 <= p) printf("悪魔が出る。");
else printf("いずれにせよ悪魔が出る。");

このプログラムの断片について議論して。前後は適当に補ってね。

どこにも悪魔は出ないだろ・・・
b + 32 は脱参照しなければ合法だし
ポインタは順序付け可能だ（どういう順序になるかは未規定だが）

p < b の大小関係が未規定ゆえ、結果が未定義となる

どういう順序になるかは未規定だが
順序付け可能とは定義されてるよ

結果は未定義じゃなくて未規定
少なくとも鼻から悪魔は出ない

When two pointers are compared,
<ばっさり省略>
In all other cases, the behavior is undefined.

未規定の動作が生じうる可能性のうちのいずれかに依存したコードには可搬性があるというのか？

ばっさり省略しすぎだろwww
同じ型なら比較可能だ

>>739
俺も今6.5.8をみていたところだが

> 同じ型なら比較可能だ

これはどこに書いてある？

>>739
同じ型でも違うオブジェクトであればだめだよ。

ああ、Cだとダメなのか。
C++だといいからCでもいいのかと思った。

>742
C++ でも駄目だろ、と思ったけど未規定なのな。
そして std::less とかだと全順序保証、と。

Cだとポインタを二分探索木で管理するには
その先の値を見るしかないのか。
その先の値の順番に特に意味が無くても。

>>744
先の値の順番に意味がなかったらなにを基準に木構成する気だ

ポインタのアドレスそのもので探索する？

連続メモリ空間上のポインタなら二分木で管理するまでもないし
そうでないなら比較の保障がない以前に意味がないだろ

×空間上のポインタ
○空間上へのポインタ

>>744
この世にはデリファレンスできないポインタも存在するわけだが。

int にキャストして比較すれば良いんじゃない

そしてオーバーフローするんですね、わかります

>>750
その比較が意味のあるものとなる保障はない。
それに>>751がいうようにintじゃだめだろう。

ポインタをポインタと同じサイズの整数型に変換可能な事は保証されてるから
uintptr_t 使うならええんでないかい？

それなら問題ないよ。

double v;
としてvがnanやinfinityであるかを判定するにはどうやるんでしょうか？
標準ライブラリ見てもそのような関数が用意されてないので困っています。
v!=vでnanなのは分かっているのですが、他に方法はないのでしょうか。
それと、実数のときと複素数のときの判定方法を教えてください。
一応GCCです。

>>755
-std=c99 でisnan、isinfあたり。

c99にすれば用意されているのですが、コンパイラ・オプションで指定しないと標準ではinf, nanは判定できないって事ですか？

>>757
いちおう、 C99 は「標準」だよ。

gcc のデフォルトは C99 じゃないけど、拡張の一部として isnan, isinf は
使えたりするかもしれない。っていうか、試せばいいよ。

そういえばinfinityの判定はやったことなかったけど、今までみんなはどうやってたんだろう・・

>>756に書いてあるじゃんw

古いAPIを読んでたのでなかったんですが、今後はコーディングするときはC99準拠で必ずやることにします。

昔も標準でなかっただけで普通にあった。
isinfinity()の環境もあった。

> 今後はコーディングするときはC99準拠で必ずやることにします。

素晴らしいです。

restrictとか可変長配列とか勝手に使うと迷惑になることもあるから気を付けろよ
個人ならいいけど

>>763
kwsk

>>764
c99ではrestrictは予約語。iccだとオプションを指定すればc++でも使える。

ところで今の規格準拠コンパイラは複素数のinf, nanを判定できるのか？

Cに複素数なんて概念あったっけ？

>>767
c99

いい加減、このスレの参加資格に、C99の規格書を読むことを入れとこうぜ

まあhttp://seclan.dll.jp/c99d/くらいは参照した方がいいかと。

確かに2009年にもなってC99を知らんのはこのスレ的にはお断りだ
Cを知らないに等しい

旧規格もそうと断ったうえでなら可だろ
事実上まだ現役だし

C99を実際には使わなくても
知っていなくてはこのスレにいる資格は無いな

まあ複素数は置いといて、何かを知らないことをもって C99 を知らないことにされたら
資格者ほとんどいないんじゃね？

今規格をあたろうとすると必然的にC99になるからそうでもないと思うが

それなら C99 を「知っている」のではなく「規格票にアクセスできる」ことが資格というべきではないか？

# 今日はここまで、遊びに出かける

でも最低でも>>770くらいのことは知っておいて欲しい

コンパウンドリテラルとか便利だけどね。
ただどれがGCC拡張か規格機能なのかよく分からないことがよくある。
それよか、API文章をC99対応にしないと広まらないだろう。
とくにMSDNが率先してC99に対応しないとGNU方面の人たちだけになるんじゃないか？
MSはカオスだしそのうち空中分解しそうだけど。

>>779
> MSはカオスだしそのうち空中分解しそうだけど。
突然それまでの話と関係ない一言を最後に入れるあたり、天声人語かと思った

コンパウンドリテラルはC++にも欲しい

コンストラクタ主義と
コンパウンドリテラルは合わない。

デフォルトコンストラクタのみなら、
リスト初期化子の記法で何とかなりそうではあるけど。

配置newで乗り切る。

配列のコンパウンドリテラルの代わりになるものは
C++0xにあるんだっけ？

まだバタバタしてますがこれ。
Initializer List
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm

initializer-list constructorってのがあって(以下上の提案参照

C90に準じていても、それをゆるさない車載標準規約であるMISRA-C。
マジでうざい規約です・・・

>>785
かなりバタバタしてる雰囲気がするねw

union { char a[4]; int i } u;

というような共用体があったとき、
u.a[0]〜u.a[3]に代入した後、それをu.iで参照するのは未定義でしょうか？
6.5のeffective typeの説明を読む限りではそうなってしまいそうなんですが。
未定義でないとすると、その根拠は規格のどの辺で規定されています？

The effective type of an object for an access to its stored value ... ってとこ？
どこに未定義って書いてある？

> 4. 規格合致性
> この規格では，このほかに，用語“未
> 定義の動作”を使うことによるか又は動作の明示的な定義を与えないことによって未定義の動作を示すこ
> ともある。

>>788
参照はして構わない。値は未定義。

多くの実装ではこちらが期待したとおりのビット列として読み出すことができる
しかし規格上は、ある型で与えた値を別の型で読み出せることは保障していない

結論：自己責任

>>792
実装の説明には書かれているものなのかな？
たとえば、gccとか。

規格で保証してないことを保証してるなら、書いてあることもある。

gccでは保証してないどころか、予想だにしない結果になるんじゃなかったっけ？
-O2 とかだと。

いやalignとかpaddingとかオプションで指定できるし。> gcc
それにconfigureで確かめたり、実行時にassertしたりできるでしょ。

ただ何がやりたいのか不明だけど、勝手に想像すると、今時のマナーでは、
#include <stdint.h>
union { uint8_t a[4]; int32_t i; } u;
とするんじゃないのかな。

何が今時なのか分からん。

sizeof(int) == 4と仮定しない方がいい→今時

>>796
サイズが同じなら、予想した動作になるってことかな？

charとuint8_tが等価なのも今時なのか？

粘着乙

char だと 0x80 の値が使えないかもしれないジャマイカ

charが9ビット以上である可能性がな・・・

>>801
いや、もともとcharで切ってたならcharとしての使い方しかしないでしょ。
なんでuint8_tにするの？ってことなんだけど。

>>803
何言っているか意味がわからんが？

> charとしての使い方しかしないでしょ。

ここはC++スレじゃないぜ？

C++が何で関係あるのか分からんが
もともとcharで切ってる事自体、
本当によく考え抜かれたものか怪しいことは確か

結局 >>788 批判ですかｗ

C++が何で関係あるのか分からんやつは答えなくてよろし

みなさま、ご回答ありがとうございます。
intとcharは例が悪かったかも知れませんが、
相談の主旨は

union U { t1 m1; t2 m2; } u;

（ただしt1とt2はcompatibleでない）

に対して、u.m1に書き込んだ値をu.m2で読み込んだときの
言語仕様についてでした。
例だと、

uの表すobjectのeffective typeはunion U
u.m1の表すobjectのeffective typeはt1
u.m2の表すobjectのeffective typeはt2

になるわけですが、u.m1とu.m2の表すobjectが同じものと考えれば、
1つのobjectがt1とt2という2つのeffective typeを持つ。
だから、u.m1に書き込んだ値をu.m2で読み込むのは許される。
ただし、読み込まれる値については未規定である。

という理解でよいのでしょうか？

そだね。

CとC++でcharの扱いが全く違うことは、
まあスレ違いなんで知らなくてもいいけど、
Cのcharがintegral typeでintegral promotionの対象、
ANSIでも"as is"が認められているだけってことは知っておかないと。

>>809
適当なことを言わないように

Cの言語仕様というと、俺はいまだにK&Rなんだが。

>>788
どうせおもいっきり環境依存なんだから、
面倒なことしないで、
char a[4]; にセットして
*(int*)a で読んじゃえ。

>808
> になるわけですが、u.m1とu.m2の表すobjectが同じものと考えれば、
とあるが、共用体のメンバに対応するオブジェクトはすべて同じなのか？
大きさも型も違うのに。

むしろ同じアドレスだけど、オブジェクトは別と考えるのが自然だと思う。

static_assert(期待通りの値が入ってるかどうか) をどっかに入れておけばいい。

>>813
strict aliasing rule違反じゃね？どうなの？

>>816
大丈夫なCPUとダメなCPUがある。
x86系は大丈夫。

逆の方が適用可能な範囲が広いか。
int a; を ((char*)&a)[0〜3] で書く。

>>816
違反。

逆に int a; を用意して (char*)&a 経由でセットし、その後 a を読むのなら OK 。

なんでC言語には累乗計算の為の演算子がないのですか？

累乗計算命令を積んでるCPUが少ないからだ

C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？

おーい誰か久弥の行方を

>>821
スレタイ嫁

ビットシフトってなんだっけ〜? あれえ〜
ビットを動かしたりするんかな〜僕ちゃんわかんない

>>821
飽きた。

しかし久しぶりに見たｗ

ビットシフトって何？

sprintf(str, "%s %d%d", str, arg1, arg2);
みたいな文字列追加をしたいんだけど、この書き方は未定義だよね

エレガントにかくためには
sprintf(strrchr(str, '\0'), "%d%d", arg1, arg2);
でいいのかな？

>>828
最初のは出力先が入力とかぶってるんで未定義。

strchr() だと元々 '\0' の検索が入ってて引数の検索とダブるから、
sprintf(str + strlen(str), "%d%d", arg1, arg2) のほうがいいだろう。

十分な領域を確保します。

>>828
>829の寝言は無視して、str + strlen(str)かstrchr(str, '\0')か、strrchr(str, '\0')でもいい。
ちょっと考えてみれば判ることだが、どの関数も原則的に先頭から'\0'を探すと言う動作を一回しか行なわない。
もしどうしてもパフォーマンスが気になるのであれば、実測して較べるしかない。

>>829
「ダブる」とは，具体的にどのような事象として定義されますか？

ってかビットシフトって何なんだ？
聞いたことないが

ggrks

ビットシフトはググってもヒットしないが

C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？

ビットシフトの存在価値がよく分からないんですが・・・

スレ違いなのでお帰りください

ビットシフトがスレ違いだと……！？

ビットシフトが何の役に立つのか分からない人は明らかにCの初心者です
このスレは初心者が来るスレではないのでスレ違いです

>>831-832
strchr(p, c) の中では↓に相当するループが実行されることになるだろ。
for (; *p != '\0'; ++p) { if (*p == c) return p; }
ここで c が '\0' なら同じ比較が繰り返されてることになり、無駄。

効率以外に strchr() の意味を考えても、引数に '\0' を渡すことの意図を
理解するには追加の情報が必要になり、無駄。

>>841
前半はともかく後半はおかしい
探索文字に\0を渡したらそれは終端を探してそのポインタを得るという意味に決まってる

>>842
あぁ実際の仕様ではそうだな。

「文字列の中から文字を探す」という（名前から考えてごくあたりまえな）認識では
理解しにくいってことね。直感的にはヌル終端文字列の「中」に '\0' は含まれない。

確かに'\0'は文字列の外という感じだな。

strlen()派の意見は出尽くしたかな?
strchr(), strrchr()派の意見はない?w

私としては、「ナル文字を探す」という関数がない以上、strchr()でもいい気はするんだけどね。
(例によって)目的が若干違っても実装が変わらないから流用するパターンってことで。
寧ろ、>843の思想からすればmemchr()の方が適切なのか? それはそれで違う気がするけど。

catsprintf()…標準外ですね

>>841
どうでもいいけど実装するとしたらこう。
for (; *p != '\0'; ++p) { if (*p == c) break; }
if (*p == c) return p; else return NULL;

以下のように実装して'\0'ではうまく動かないlibcありそう。
for (; *p != '\0'; ++p) { if (*p == c) return p; }
return NULL;

どうせそれを言うならこうだ

for( ; *p != c ; ++p) if(*p=='\0') return NULL;
return p;

規格関連の話かと思ったら単なる「無駄だからやめれ」かよ

あげればいいのかな？

>以下のように実装して'\0'ではうまく動かないlibcありそう。
>for (; *p != '\0'; ++p) { if (*p == c) return p; }
>return NULL;

文字列の「中」に'\0'は含まれない派にとっては
こっちが正しい実装だな。

規格上は終端ヌル文字も検索対象に含まれることになってる

本質的には'\0'までで文字列だよ、無いということはありえないんだから
文字列の長さと文字列の大きさは違う

末尾が\0なものを「文字列」というわけだが。
\0も文字列の一部であるに決まっておろう。

>>853-854
こういう議論が発生したりそういう説明が必要になる点を指して >841 の
「追加の情報が必要に」って話だろ。やっぱり strlen() 使ったほうがマシだ。

>>855
ガチすれで何を言っている。

規格に「文字列」の定義があるんだから
追加の情報も何も無い。自明なことだ。

で、ビットシフトってどうやんの

じゃあstrlenが返す値は何だよ。
長さの元の文字列に'\0'は入らないだろ。

こうやるの。
a >>= 2;
a <<= 1;

>>858
長さと大きさは違うと>>853が教えているだろうに。

>>859

>>859

>>859

>>859

>>859

7.21.5.2 The strchr function
Synopsis
1 #include <string.h>
char *strchr(const char *s, int c);
Description
2 The strchr function locates the first occurrence of c (converted to a char) in the
string pointed to by s. The terminating null character is considered to be part of the
string.
Returns
3 The strchr function returns a pointer to the located character, or a null pointer if the
character does not occur in the string.

結局ビットシフトって何の役に立つんですか？

ここに答えられる奴はいないからｗ

きになる

あげるか

>>867
あなたにはこのスレは早すぎます
初心者スレで聞いてください

あげるよ

ください

なるほど、「スレッドを上げる」という宣言に対して、意図的に「何かモノをあげる」とミスリードして
「ください」と返答すると言う、言葉遊びなわけですね?　これは面白い。

hoge_t *p = malloc(sizeof *p);

というのはC89で合法的ですか？
教えてください。

なぜ合法的でないかもと思ったんだ？

合法に決まっている
何もおかしいところはない

ただ、君が想像している動作を実行してくれるコードではないかもしれない

>>876
変数のスコープがどこから始まるかわからなかったからです。

そこまではいいが、なぜ便所の落書きに確認に来るんだ？　相手が違うだろー

便所の落書きであっても人類の生み出した物である以上、
なんらかの意味を持っていると考えられるからです。

>>874
「ミスリード」の用法覚えてから来い

Verb
to misread (third-person singular simple present: misreads; present participle: misreading; simple past and past participle: misread)
　1. To read wrongly, normally by accident.

英和辞書との一致 (1〜2件目 / 2件) 検索辞書：プログレッシブ英和中辞典　提供：JapanKnowledge

mislead
[動]（-led, 〜・ing）(他) 1 〈人を〉誤った方向に導く［案内する］；〈人を〉（…に）誤り導く((into ..., doing))

Main Entry: mis・read
Pronunciation: \?mis-?r?d\
Function: transitive verb
Inflected Form(s): mis・read \-?red\ ; mis・read・ing \-?r?-di?\
Date: 1658
1 : to read incorrectly
2 : to misinterpret in or as if in reading <totally misread the lesson of history ? Christopher Hollis>


Main Entry: mis・lead
Pronunciation: \?mis-?l?d\
Function: verb
Inflected Form(s): mis・led \-?led\ ; mis・lead・ing
Date: before 12th century
transitive verb
: to lead in a wrong direction or into a mistaken action or belief often by deliberate deceit
intransitive verb
: to lead astray : give a wrong impression

>>875
未初期化のポインタをデリファレンスしてるから未定義動作だな
sizeofの中だから実際に参照するわけではないとはいえ未定義は未定義

sizeofのオペランドは評価されず、sizeof式の値はオペランドの型で決まる。
（ただし、オペランドが可変長配列の場合を除く）

よって>>885は誤り。

0xFFFFFFFF
この定数は signed なのでしょうか、unsigned なのでしょうか、
それとも文脈によって判断されるのでしょうか？

特に何もないかぎり、ほとんど全ての型はint型になる
つまり以下略

規格は読んだこと無いが
いわゆる汎整数格上げと同様に扱われるとどこかで読んだ。
要はintで収まるならint、だめならunsigned int、それでも駄目ならlong、さらにはunsigned long、とね。
例えばintが16bitな環境ならば、unsigned longになるだろうし
同64bitであるならば(signedな)intになるだろう。
必要ならばUやLなどを付加して扱うことも出来る。

0xFFFFFFFFに関しては、unsigned longには確実に収まることが保証されているから
それ以上の幅を要する(独自拡張の)型として扱われることは無い。

ただし、C++においての''で囲まれた定数はcharやwchar_t(及びその符号有無の派生型)とされ
intとしては扱われないはず。
これらは、C(C89)においてはint。

>>889
BCCでint64に代入したら-1になったぞ？

ごめん勘違いだった

フルートの最低音の C が出せないのですが、どうしたらいいですか？

練習すればいい。

どう練習したらいいですか？

吹いて吹いて吹きまくれ

>>892
オーパッキャラマド

C９９って、けっこう変な構文入ってたんだね。
VC++でも対応してくれないかな。

>>897
変な構文って何？

>>897
このｽﾚで世間話たぁいい度胸だ！

ttp://seclan.dll.jp/c99d/c99d07.htm#dt19991025

いいよC99なんて廃れる一方だから

名前で初期化は有用だろう?

現在、マルチプラットフォーム(主にLinux向け)なフリーソフトウェア(フリーソフトウェア != オープンソースソフトウェア)
をISO/IEC 9899 : 1990 (E)[以下C90]準拠で開発中です。
ライブラリは、7割くらい完成しており、よりパフォーマンスをよくしたバージョン(ISO/IEC 9899 : 1999 (E)[以下C99]準拠)
も条件コンパイルなどでコンパイルできるようにしています。
つまり、最小限のC99準拠で作りつつC90でもコンパイル可能なようにしている状態です。

この度、マクロの引数が空の場合の性質、つまり、C99の6.10.3.2 The # operatorの
2 The character string literal corresponding to an empty argument is "".
という性質、を使いたいと考えています。

これをC90で同じようなにするにはどうすればよいでしょうか。
最悪の場合、今後はC99準拠だけで進めることも考えています。

ああ、C90の亡霊に取り付かれたか。C1xに期待しよう。

>>898
コンパウンドリテラルだろ。ｊｋ

最近は慣れてきて、便利でラクだから
けっこう使うけど、冷静になるとやっぱり
ちょっとキモい。

>>903
＞この度、マクロの引数が空の場合の性質、つまり、C99の6.10.3.2 The # operatorの
＞2 The character string literal corresponding to an empty argument is "".
これって具体的には何のこと？

>>905
例えば、
$ cat hashop.c

#include <stdio.h>

#define Foo(Bar, Baz) \
fprintf(stderr, # Bar # Baz "\n")

int
main(void)
{
Foo(foo, bar);
Foo(foo, );
Foo(, bar);

return 0;
}

/* EOF */

$ ./hashop
foobar
foo
bar
のようになるわけです。
ちなみに、C90では、置換リストが空では、有効な文字列は作れないので未定義の動作です。
3.8.3.2 The # operator
... If the replacement that results is not a valid character string literal,
the behavior is undefined.

そこをなんとか似たようなマクロが作れないかと考えているところです。

#define _ ""
Foo(_, _);
Foo(foo, _);
Foo(_, bar);

>>907
しかしそれでは、プロジェクト全体で、
_
を使うなということになるではないですか。

いやもっと深刻な事に、
_
を含む標準関数や他のライブラリも使えないことになりますので、
まったく解決になっていませんね。

>>909
まさか。_一文字の標準関数なんかあるもんかいw

宿題スレでこんなのがあったぞ。

751 名前: デフォルトの名無しさん Mail: sage 投稿日: 2009/05/13(水) 09:23:27
じゃあ同じO(n)でももっと変態な方法を

typedef struct { int a, b; } intx2;

intx2 fib2(int n) {
if (n == 0) {
return (intx2){ 0, 1 };
} else {
intx2 s = fib2(n - 1);
return (intx2){ s.b, s.a + s.b };
}
}

int fib(int n) {
return fib2(n).a;
}

>>910
C99のソースは無視しろ
オナニーに過ぎない

ちゃんとコンパイルできるんだし別にいいじゃん。
コンパウンドリテラルや for (int i=0; ...) みたいな書き方や
ブロック内の文の後の宣言なんてもう普通に使うだろ？

>>909
さすがに_が識別子な標準関数は、わたしも見たことないです。しかし、準拠と名乗る限り_は識別子として利用できないです。

C90
4.1.2 Standard headers
... All external identifiers that begin with an underscore are reserved.
All other identifiers that begin with an underscore and either an
upper-case letter or another underscore are reserved. If the program
defines an external identifier with the same name as a reserved
external identifier, even in a semantically equivalent form, the
behavior is undefined.
ということで、_, _identifier, _A, _B, ..., _Z, __は、予約済みのようで、
ぶつかったら未定義の動作です。

C99
7.1.3 Reserved identi?ers
- All identi?ers that begin with an underscore and either an uppercase letter or another
underscore are always reserved for any use.
- All identi?ers that begin with an underscore are always reserved for use as identi?ers
with ?le scope in both the ordinary and tag name spaces.
ということで、_A, _B, ..., _Z, __は、いろんな用途に備えて常に予約済みで、
_, _identifierは、普通の名前空間やタグ名の空間においてファイルスコープとして
識別子を使うことに備えて常に予約済みのようです。

identifierについては、それぞれの規格のidentifiersの項に従います。
C90では、使うべきでないで、C99は、ファイルスコープだから使っても良さそうかもです。

#define _ ""
は一応候補にあげさせていただきます。
C99準拠にすれば、すべて解決するわけで、さらばC90の亡霊forever~~といきたいところでもあります。

文字化け警告が出ています。このレスは文字化けをしているかもしれません。

Intel C++はC99に100％準拠しているが俺にIntel C++を買えと申すか
GCCは100％C99に対応してないので使わないようにしている

試しに
#define _ ""
がうまくいくかやってみました。
あっさりダメでした。おそらく、プリプロセッサのフェイズによるモノと思われます。
今日は忙しいので、休日にでも規格書を眺めようと思います。

しかし、ここで気がつきました。
$ cat hashop.c

#include <stdio.h>

#define ToStr(s) \
# s
#define Foo(Bar, Baz) \
fprintf(stderr, "%s%s\n", \
(ToStr(Bar)[0] == '#') ? "" : ToStr(Bar), \
(ToStr(Baz)[0] == '#') ? "" : ToStr(Baz) \
)

int main(void) {
Foo(foo, bar);
Foo(foo, #);
Foo(#, bar);

return 0;
}
例えば、このようなものを。
#は、プリプロセッサディレクティブの始めを表すため、
先頭は、空白であり、後ろは、ディレクティブである必要があります。
また、# operatorは、マクロ内でしか使えないので、#単独は、ありえない構文となってくれます。
本来、省略したかった引数ですが、#が必要になって少し美しくなくなりましたね。
結果は、>>906と同様。一連の流れ、>>903,905-909,913,915

>>908
>_
>を含む標準関数や他のライブラリも使えないことになりますので
どういう勘違いなんだコレ。

頭悪いだけだろ

そんなトリッキーな書き方が必要なのは、そもそも
そういう書き方を必要とするコードというか、
やりかたのほうが間違ってる気がするんだけど...

#define Foo(A, B) A##B
#define Foo1(A) Foo(A, "")
#define Foo2(B) Foo("", B)

みたいなのではダメなのか

だめだろ。

なにもわかっちゃいねえな

C99で
int a[i];
みたいに配列を扱えるようになったけど、
これってC++でもサポートされてる？

>>921
貴様はスレタイ読めないのか…

以下の13行目のキャストは、規格的に問題ないでしょうか。
知りたいのは、const外しをしていることです。
なぜ、このようにしているかは、ヒープからオブジェクトを作ったときにconstなメンバを初期化したいからです。
$ cat -n piyo.c
1
2 #include <stdlib.h>
3
4 struct foo{
5 int * const piyo;
6 };
7
8 int main(void)
9 {
10 struct foo *fuga = malloc(sizeof(struct foo));
11 int i = 0;
12
13 *(int **)&fuga->piyo = (int *)&i;
14
15 free(fuga);
16
17 return 0;
18 }
19
20 /* EOF */
21
実際には、もっと複雑ですが、動作する最小限のコードにしました。
一応、コンパイラとバージョンを以下に示しておきます。
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)

>>923
規格上問題は無いはず。

しかして*(int **)&fuga->piyo = &i;で十分ジャマイカ？
(int *)は冗長。

つーか、fuga->piyo = &iでいいのでは?

>>925
constが目に入らないの？

>>923
C99なら複合リテラルとか。
*fuga = &(struct foo){&i};

ま　た C99厨　か

#define const

>>928過敏症いらね。
今の規格はC99です。

>>930
10年たってもコンパイラがないようでは。

>>930
そういう事
君の言っている事は現場では机上の空論に過ぎない

既にあるものをないことにしたいんですね、判ります。

GCCがC99にほとんど対応してだいぶたつのに、
ttp://gcc.gnu.org/c99status.html
まだ脳味噌が10年前な奴がこんなにいるのか。

「ほとんど対応してだいぶたつ」というのは、
「いつまでたっても完全対応しない」ってことかな。

>>934
ほとんどってどの位？
％で表してみ
どっかにステータス表があったと思うけど

それからお前は人にgccを使う事を強要する権利はない

ただ存在すると書いているだけなのに、強要したことにしたいんですね、判ります。

開発に使うコンパイラがC99対応してない
頭を切り替えてC89でコーディング->普通
頭を切り替えできずコンパイラをこき下ろす->開発者に向いてない

それだけ

ISO/IECの認定を受けたからと言って既に終わってる言語はたくさんある
FULL-BASICとかLOGOとか

多くの方ありがとうございます。話が別の方に行ってしまっているような気がしますが・・・。

>>924
たしかに、C言語では、不必要なキャストですね。

>>927
言うのを忘れていましたが、C89(ANSI X3.159-1989)準拠でお願いします。
C99(ISO/IEC 9899 : 1999 (E))準拠の方は、オナニーしたいだけでしょうか。

Rationale for American National Standard for Information Systems - Programming Language -C
の3.5.3 Type qualifiersには、The Committee considered making const and volatile storage classes,
but this would have ruled out any number of desirable constructs,
such as const members of structures and variable pointers to const types.
とあり、そもそもconstな構造体メンバを作るべきではない感じなのですよ。

同3.3.4 Cast operatorsには、It is possible to cast a pointer of some qualified type (§3.5.3)
to an unqualified version of that type. Since the qualifier defines some special access or aliasing property,
however, any dereference of the cast pointer results in undefined behavior.
とあり、可能である。しかし、修飾子は、特別なアクセスや別の属性？を規定するので、
キャストしたポインタのいかなる逆参照も未定義となる。
つまり、規格では、以下の形を未定義としているようです。
const T var; *(T *)&var;
今回の場合、typedef int *T;とすれば、規格未定義形と同じ形になります。
const T var => int * const varになりますから。

みたいなのですが、今回は、ヒープに取ったただのバイト列ですし、
ポインタなんてただのビット列ではないか、変更しても問題ないだろというのが私の結論です。

私では、解決できそうにないので、誰か優秀な言語弁護士さんは、いらっしゅいませんか。
-Wcast-qual付けると、警告してくれますので、やらない方がいいのかなといいのかな、と思いつつあります。

結論、constを剥がしたいと思う時点で間違い。
間違いを承知で突き進むのなら、自分の思うがままに進めばいいだけ。

>>935
じゃあc89に「完全」対応してる処理系を挙げてみろよ。

>>942
話を逸らすなよみっともない　(´ー｀)y─┛~~

たとえC99完全準拠コンパイラを使おうとも、C99の機能なんか使うべきではない
C89やC++への移植性が失われる上に、単独でも有害な機能ばかりだ

>>940
それはもう規格スレの範囲じゃないような。

規格的にはOKでしょ。心情的に気に入らないみたいだけど

>>941
間違いではない。
const外しは規格として問題がないはず。

ただし、その結果は保証されないだけ。ｗ

結果が保証されない、というのは弱い言い方だな
要は未定義だ

そもそも>>927がC99でもコンパイルエラーだと指摘するのが先決ではないだろうか。
この中で927が一番C99を語る資格がないと思う。

>>948
違う。いわゆる未定義ではない。

記述としては正しいが、書き込んだ先が
ROMでないことは保証されないだけ。
言語規格と実行環境は別の話。

ROMなんて言葉を使ってないで、規格を読んでください。

C言語をはじめたばかりであまりわからないのですが、
ビットシフトはなんの役に立つのでしょうか？

>>952
例えば、32bit符号無し整数の変数があり、
先頭から8bitごとにARGBを表しているとする。
(32bit画像の1画素)

すると例えば、値を使用する前に2つを分離しなければならないから、
以下のようにする。

a = (x >> 24);
r = 0xFF & (x >> 16);
g = 0xFF & (x >> 8);
b = 0xFF & x;

なんだ、コピペか。
普段読まないスレなので、答えてしまった。
スレ汚しスマソ。

普段読まないスレにきてスレ違いの話題に答えていくってどんな荒らしだよｗ

よくあること。

暇なら規格書読んどけ。

C言語を始めようと思うのですが、ビットシフトはありますか？

Rationale for American National Standard for Information Systems - Programming Language - C 3.3.7 Bitwise shift operators
ISO/IEC 9899:1999 (E) 6.5.7 Bitwise shift operators
ISO/IEC 9899:201x WG14/N1336 6.5.7 Bitwise shift operators
を参照してください。

あります

>>959
>>959
>>959

Type 型オブジェクトの配列への参照を受け取る関数を定義するとき
f( Type* array, size_t size ) と f( Type array[], size_t size ) は
どのように使い分けるのでしょうか?

あんま意識してないが、元が配列なら array[]、
そうでなけりゃ *array に (だったら名前として array はないが)
してる…かなあ。

そういや、&配列名って正式にOKになったんだっけ？

>>962
その区別にたいした意味はない。

使い分けなんか考えずに、かならず
ポインタ型にしとくのがいいと思う。

>>964
大昔からおｋ。

そもそも同義だから、使い分けはコーディングスタイルの管轄

うどんがヤバイのですが、どうしたらいいですか？

ゆですぎただけなら冷水でしめてしまえばいいよ。
乾麺のカビなら、餅と同様に取ればいい、が、面倒。

まず匂いかいでみたら？

以下を実行した後は必ず b == p は成り立つでしょうか？

Type* p = malloc( sizeof( Type ) );
size_t a = (size_t)p;
Type* b = (Type*)a;

それは、size_t≧ポインタという保証はあるか、ってことか。
ついでに低レベルなことを聞かせてくれ、すべてのポインタ型が同じサイズという保証はあるの？

>>970
C99§6.3.2.3¶5
> An integer may be converted to any pointer type.
> Except as previously specified, the result is implementation defined,
> might not be correctly aligned, might not point to an entity of the referenced type,
> and might be a trap representation.
ただし "previously specified" は整数定数0から空ポインタへの変換に関する規定を指している。

C99§6.3.2.3¶6
> Any pointer type may be converted to an integer type.
> Except as previously specified, the result is implementation-defined.
> If the result cannot be represented in the integer type, the behavior is undefined.
> The result need not be in the range of values of any integer type.
ただし "previously specified" はポインタから_Boolへの変換に関する規定を指している。

一般の整数型とポインタ型の型変換に関して定められているのは以上のみで、
変換可能性については定義されているが、値が同じになるかどうかはわからない。

C99§7.18.1.4で、intptr_tとuintptr_tに関しては、
全ての汎用ポインタをこれらの型に変換したものを汎用ポインタ型に逆変換すると
もとと等しい値になることが保証されている。但し、これらの型の実装はオプショナル。

すなわち、次のコードは期待通りに動く:
| Type* p = malloc( sizeof( Type ) );
| intptr_t a = (intptr_t)(void*)p;
| Type* b = (void*)a;
| assert(p == b);

C89やintptr_t/uintptr_tの存在しないC99処理系では、
一般にポインタ→整数→ポインタのラウンドトリップな変換をする方法はない。

完全に蛇足だが付け加えると、size_tがポインタを格納できる大きさだという保証はない。

>>971
ない。

>>972
なるほど C89 では特定の処理系を前提としないと無理みたいですね。
整数に単射変換できるとポインタ値をキーとした辞書を作ることができるのですが。
C++ の std::less<Type*> に相当するポインタ比較はできないかな。

>>974
残念ながらできない。

>>974
uintptr_ｔを使えばいいじゃん。
なければ自分で定義したっていいんだし。

>>976
アホ？uintptr_ｔはC99以降だし、C99準拠でも存在すると限らない。
それに、標準Cの範囲内でuintptr_tを使わずにuintptr_tを定義することは出来ない。

>>977
アホ？
Cは自分で動作保証するもの。
わかったうえでtypedefするなら問題ない。

別のスレいけよカス

・規格に準拠した実装を自分でしたい奴
・規格に準拠した実装にこだわる奴

どっちでもよかろう。けんかすんな。

質問者は標準Cの範囲内で出来るかどうか効いているのに、
なんで自分でtypedefしろとか言い出すわけ？意味不明だわ。
完全にスレ違いだろ。

動きゃええんや
標準なんてクソ食らえやｗｗｗｗｗｗｗｗｗ

俺が標準だ！

動かなくても<丶｀∀´>ケンチャナヨ

>>981
標準Cにtypedefがあるからじゃないの？
・標準Cでtypedefをしたところで、uintptr_tと全く同じものを作ることはできない
・標準Cでは実現できない部分をしっかり把握した上でtypedefすればよい
という話だと思う。よくわからんけど。

別にtypedef派を擁護する気はないが、
規格に準拠した上で、typedefしていれば、
私はこのスレの趣旨と合っていると思う。

規格を無視した発言をする方はさっさと巣に帰ってくれ。

$ sed -n 117,130p /usr/include/stdint.h
/* Types for `void *' pointers. */
#if __WORDSIZE == 64
# ifndef __intptr_t_defined
typedef long int intptr_t;
# define __intptr_t_defined
# endif
typedef unsigned long int uintptr_t;
#else
# ifndef __intptr_t_defined
typedef int intptr_t;
# define __intptr_t_defined
# endif
typedef unsigned int uintptr_t;
#endif
私の環境では、#define __WORDSIZE 32だった。
これと同じことは、C89でも可能だから。

もっとも、>974のstd::less<Type *>がどのようなものかは知らないが、
a pointer to an object同士の比較演算は規定されている。ANSI C 3.3.8 Relational operators
任意のポインタはvoid *に変換できる。また、void *から元のオブジェクトのポインタへ変換できる。ANSI C 3.2.2.3 Pointers

わかんないなら黙ってろよ…
さすがに外しすぎ。

問題:
　処理系に依存せずにuintptr_t相当の型を定義できるか？

>986の答:
　__WORDSIZEという処理系独自マクロを使えばok。

規格書も見ないでヘッダファイルを見る男の人って。

>>986
以下の &a, &b, &c 間の関係演算の結果は未定義なので以下が通ってしまうことがある。
確か std::less<ポインタ> は推移的だったような気がする。

int a, b, c;
assert( &a<&b && &b<&c && &c<&a );

>>987
自分が分かってないことすら分かってない人にそんなこと言っても無駄です。