C言語なら俺に聞け 143
レス数が950を超えています。1000を超えると書き込みができなくなります。
バスエラーってのは、あらかじめ決めた領域以外をアクセスしょうとしたら発生するのであって、読んだ後にここ読めないからなんて動作はしない。
むしろ決めて無い場合は幾らでも読み書き出来てしまう。例えそれが嘘でも虚構でもな。
後からノーカンなんてならない。 >>871
>例だね
ヌルポインタ以外に特異点はないのでは? >>872
奇数アドレスからのワードアクセスでもでるぞ
なんとかしてくれる方が少数派かと >>874
それは命令アドレスのLSB見りゃ即出せる罠 >>872
わかってない奴は割り込むなって言っただろ
痛々しいぞ >>876
お前がわかってないだけだろ w
68K の話ならデータが読めると言うのは DTACK のアサートで示される
その後に BERR をアサートしても受け付けなかったと思う
(そんなアホな設計はしたことないから本当にそうかどうかは試してないけど)
そもそも BERR は非同期じゃないからお前が初めから頓珍漢なだけ >>874
68000 の時代はデータでもダメだったけど今時はプロセッサ側で何とかするアーキも多いと思う intelの石はワードやロングワードのアクセスでも奇数アドレスからだろうとマシン側で何とかしてくれるから生き残ってるんだと思うわ プログラミング歴1年になったけどみんなの言ってることがわからなさすぎて辛い
アセンブリもやった方がいいんか? >>879
普通に組んでてあまりありがたみを感じたことはないけど... >>835
hogeがでかい配列で、オフセットの位置に確かに値が書かれているのを確認したことがある。
0番地付近のメモリを参照する人はいい迷惑だなと思った >>852
ゆとりマジで死ね
韓国人も死ね
お前らはそういう所がいけない。俺は逆ギレしているのではなく、単にキレてるだけだ。
お前らはそうやって常に話をすり替え、被害者ポジションを確保する癖があるが、それは根本的に間違ってる。
そもそも、ここにはお前らより知識のある奴が沢山居るんだから、お前らの聞きかじりで回答する必要はない。
話が余計におかしくなってるだろ。
話を>>841に対する回答に戻すと、841の話しぶりからして、
俺は以下を補足した方がいいと思ったから>>843を投稿したんだよ。
1. 841の言う「ヌルポ」はOSがMMUで捕まえるヌルポである。
2. >>838の言う「組み込み」はMMUがない場合を指している。
3. 838の言う「ゼロ番地付近をアクセス」はOS+MMUがない場合を想定している。
4. 従って838のケースでは841の想定するヌルポは発生しない。
というのを伝えるために書いたんだ。
それをお前は知ったかをしたくて、「MMUなら俺も知ってる!」と勝手に食いついてきただけ。
読む限り、お前は例外がどう動くのか理解できてないと分かるが、無知なままでいろ。
俺は841を助けようとしたのであって、韓国人とゆとりは死ねとしか思ってないから。
VBRを変更する場合、確かに0番地付近を構造体アクセスして転記するんだよ。
838はこれに気づいた、そしてそれを伝えた。
俺は841が「0番地アクセス=ヌルポ」と思っているっぽいので、(これは通常のOS+MMUならそうだが)
それとは違うぞと分かるように補足した。
それに知ったかゆとりが食いついてきただけ。
> プログラミング初心者です (>>835)
という点からしても、838で当たりだろう。
VBRを変更するならかなり初期で対応するので、初心者でも目に付く場所に記述される。 >>835
それをコンパイルするコンパイラの仕様とそれを実行するマシンアーキテクチャによって変わる。 OSによっても変わるかな。
まあしかしOSそのもののソースコードならそう書いて正常動作したとしても特におかしくないかな。 >>882
うん普通は何も考えない。
だから他の石を同じ感覚で使ってポインタ渡しした構造体のメンバーにアクセスして焦るんだわ。
intelの石ならこんな事起きないのにってな。 >>888
ゆとり死ね
てかマジな話、知らないのならちょっと様子見する余裕を持てよ。 >>891
ゆとり死ね
俺はその理由も既に書いてる 過去レスまでちゃんと読んで欲しいならコテ付けること☆ 1点、気になるのがNULLと書いていたことだ
0番地にアクセスすることを意図しているコードは
struct hoge *tmp = NULL; ではなく
struct hoge *tmp = (struct hoge *)0; と書くだろう
思うに、単にtmpへの代入を忘れただけではないか?
そういうポカミスを多発するどんくさいやつほど
「変数は必ず初期化」に固執する >>894
まあ、ゆとりとか韓国人とか言い出す時点でお察しって奴やね w >>893
ゆとり死ね
韓国人死ね
俺が読めといっているのは>>884のことだ馬鹿タレ
どうせお前らは日本語が不自由で3行以上は読めないから意味が分からないのだろうが
お前らが迷惑行為を働くことに対して俺はキレてるんだよ
>>895
環境によってはwarningが出る。VC++とか。
個人的には意味ないとも思うが。 MMU とか VBR とか知ってる言葉を必死に使ってるって感じが出てて微笑ましいな >>895
初期化してなきゃ警告が出るのにね
>>897
お前は的外れなことしか言わねーな C言語に関する話題で意味のある文脈で韓国人なりゆとりなりが出てくることはまず無いだろうから、NGしとけばいいな。 >>898
その程度の用語で威張れると思える時点で終わってる
ゆとりは本当に馬鹿だな
ゆとり死ね
韓国人死ね > その程度の用語で威張れると思える時点で終わってる
>>884に言ってやれよ w >>903
ガチアスペか?
韓国人か?
それじゃ論理が通らんだろ
ID:KXDpqAfSM = ID:FCwL/bM6M = ID:wOa8xeUW0 = ID:tW10X6gZ0 = ID:JlwKPeYd0
お前だけがぶっちぎりの馬鹿だな
韓国人死ね NULLが(void *)0になったのっていつからだっけ
C89には無かったよね? おっぱいおっぱいぽよんぽよん
おっぱいおっぱいぽよんぽよん
仲良くしようぜ >>906
つまりこうであると。
#include <stdio.h>
int main(int argc, char *argv[])
{
int i, j;
for (i = 0; i < 2; i++) {
for (j = 0; j < 2; j++)
fputs("おっぱい", stdout);
for (j = 0; j < 2; j++)
fputs("ぽよん", stdout);
putchar('\n');
}
return 0;
} そういや古いソースには char *p なのに if (*p == NULL) みたいに書いてあるのがあって、今時のコンパイラだと警告出しまくりになるんだよなあ。 >>908
こう書いてもいいね。
#include <stdio.h>
int main(void) {
int i;
for (i = 0; i < 8; i++) {
if (i % 4 < 2) fputs("おっぱい", stdout);
else fputs("ぽよん", stdout);
if (i % 4 == 3) putchar('\n');
}
return 0;
} NULLの値が、0xDEADC0DEになってる環境なら知ってる。 >>904
頓珍漢な奴に論理とか言われてもなあ w >>910
なるほど。
ちょっと変形してビット演算でも行けるな。
#include <stdio.h>
int main(void) {
int i;
for (i = 0; i < 8; i++) {
fputs(i & 2 ? "ぽよん" : "おっぱい", stdout);
if ((i & 3) == 3) putchar('\n');
}
return 0;
} #include <stdio.h>
#include <stdlib.h>
void o(){ fputs("おっぱい", stdout); }
void p(){ fputs("ぽよん", stdout); }
void r(){ puts(""); }
void e(){ exit(0); }
void (*a[])() = { o,o,p,p,r,o,o,p,p,r,e };
int main(){ void (**x)()=a; while(1) (*x++)(); } >>877
>struct hoge *tmp = (struct hoge *)0; と書くだろう
このように書いても*正しく*NULLポインタが代入される
char zero[(struct hoge *)] = {0};
memcpy(tmp, zero, sizeof zero);
としないとダメ
逆によく見かけるポインタを含む構造体をmemcpyで0に初期化するのも正しく無い >>915
それがわからんやつが、ここに、いや世界にいると思っているのか?
俺のはコードに意図を残すという論旨だったが、それがわからんやつがおまえさんか
ア ホ か 意図を残すために間違ったコードを書くとは理解に苦しむ
コメントで残した方が数百倍マシ >>915
いったいそれと BERR になんの関係があるんだ?
ますます頓珍漢過ぎる w >>912
連呼リアン死ね
>>919
アスペ通り越してキチガイか?
まあどっちにしても死ね >>919
>>895と間違えてたな
>>921
memcpy(&tmp, zero, sizeof zero);
こうだね >>920
> アスペ通り越してキチガイか?
基地害はお前だろ w
>>915のアンカー先見ろよ 完全初心者です。文字列の性質について質問させてもらいます。
柴田望洋著 「ポインタ完全攻略」という書籍にて次のような内容の記載があります。
・文字列リテラルは変数ではないが記憶域を占有する
・文字列リテラルはcharの配列である
そして次のページに、
・このような文字列リテラルは、整数にいいかえると「定数」に相当するものであるから、自由に取り扱うためには
変数に格納する必要性がある
・そこで利用されるのがcharの配列である
ここでわかりかねるのが、文字列リテラルというのはそもそも定義自体が「charの配列」であるはずなのに、
これをまた「charの配列」に格納するの??と、疑問に思ってしまったわけです。
これはいったいどういうことでしょうか。 >>926
謎
通常配列名かcharのポインタで参照するぐらい。 "This is C string literal."
これが文字列リテラルね。参照すると文字列定数になる。
char s[] = "This is character array.";
これが文字の配列の変数sの宣言と初期化ね。sはヌル文字を含めた文字列データ先頭を参照する。sizeof(s)は、ヌル文字を含めたデータのサイズになる。
const char *p = "This is pointer to characters.";
これは文字列の先頭へのポインタになる。サイズはアドレスのサイズ。データは変更できない。 >>926
ちょっと進んだ知識になるのですが。
プログラムがコンパイルされたのち、プログラムの実行の段階にはいったとき、コードや変数領域やその他もろもろがメモリ上に展開されるわけですが、
文字リテラルは、場合によってはメモリ上の書き込み不可能の場所に置かれます。たとえば ROM メモリとか。
もし、その文字リテラルを適宜書き換えて使いたいのならば、書き込み可能な場所にコピーして使うでしょう、それが、変数であり配列でありするわけです。
ただし文字リテラルを書き換えることが可能な環境では、それを見越して、文字リテラルを書き換えて対応する、という手がないわけではありません。
まあ一般的には行儀が悪いと思われています。それに文字リテラルを途中で長くしたい、とかは不可能ですし。 >>926
おまえさんが疑問に思っているのはこういうことか?
puts("aho"); で済むのを、わざわざ
static const char array[] = "aho";
puts(array); としなければならないのかと 複数の文字列の先頭番地を便利に参照したいぐらいじゃないかな。 >>927
>>928
>>929
>>930
>>931
みなさんお騒がせいたしました。みなさんから頂いたアドバイスを参考にさせていただいて、
よく考えてみたところ、あまり深く気にするべきではないように感じてきました。
先ほどの本の「配列による文字列」「ポインタによる文字列」という箇所を読み込んだところ、
「配列による文字列」はcharの配列を宣言して文字列を用いる場合で、「ポインタによる文字列」
は「char p* = "ABC"」のように、ポインタchar *を宣言してなんらかの文字列リテラルで初期化する
手法であるとのことです。
おそらく・・・よくわかりませんが、直観的に私が当初感じていた疑問点というのはここら辺の部分に帰結
する話だと思われます。
現段階での私の理解
・文字列はそもそも配列?などということは気にしなくてもよい。
・文字列を配列charに格納してからポインタで操作する方法がある。この場合は当然配列の規則に従う
ので代入とかはできない
・char * = "ABC" のようにchar[]を宣言せずに文字列をポインタで操作する方法もあり。
この場合は p = "SEX" のような代入ができる。 char *p = "string";
はconstがない時代の古い書き方だよ。
良い子は
const char *p = "string";
のようにconstを付けること。 >>933
const
中身を変えられないとかいう…。
ありがとうございます。勉強になります。 immutable・不変かどうかの区別。
不変オブジェクトは、メモリ内の読み込み専用エリアに置けるので、最適化しやすいから、
できる限り、不変が望ましい
Ruby, JavaScript では、文字列は可変オブジェクトだが、freeze すると更新できない
s = "hello"
s.freeze
よく覚えていないけど、この本が良かった気がする。
詳説 Cポインタ、オライリー、2013 char *s = "abc";
と初期化した場合は
s[1] = '\0';
のようなことをすると Segmentation fault になったが、
char s[] = "abc";
の場合は
s[1] = '\0';
が問題なくできた。その後 puts(s) をすると a だけが出た。
OS は Linux でコンパイラは gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16) だ。
-S でアセンブラの出力をさせるとどちらも "abc" をリードオンリーの領域に配置させているが
char s[] と書いた場合は関数の初めでスタックに領域を確保してそこにコピーしてからアクセスしていた。
char *s の方は単に先頭アドレスを使うようになるだけ。(そしてリードオンリーの領域に書いて死亡)。
man gcc を見ると -traditional や -fwritable-strings で文字列リテラルに書き込めるようにできるとは
書いてあるが、この man page 自体が古く、4.8.5 では既にこのオプションは使えなくなっていた。 >>932
> 現段階での私の理解
だいぶ間違っているが、ド初心者ならあまり細かく考えずに進めてもいい。
(プログラミング自体の初心者なら、最初の段階で重要なのはそこではないから)
キッチリやりたいのなら、メモリを確認しながら進めた方がいい。
IDE等使えば簡単に見えるし、何を間違っているかすぐに理解できると思う。
>>935
JavaScriptのstringはインミュータブルだ馬鹿タレ >>932
よく言われることだけど、cに文字列型はない
cで文字列という時は必ず文字の配列のこと
char * p = "ABC";
は
char x[] = { 'A', 'B', 'C', 0};
char * p = x;
って書くのを少し楽に書けるようにしてくれてるだけ
プログラミング自体の初心者なら、cで文字列を扱うこと自体を後回しにした方がいいと思う > cで文字列を扱うこと自体を後回し
俺もそう思う
ど初心者にはちとキツい char x[] = { 'A', 'B', 'C', 0}; は.dataに保存されるから同じじゃないだろ。 ROMに追い出すconstの嵐w
#pragma でもいいけれど。 C++にconstexprがあるのはconstの設計ミス >>944
いや、const無くても文字リテラル自身はROMに書かれてるんだけど、デフォルトはそれをわざわざ初期化の時にRAMに展開して書き換えられてもいいように準備して待ってるんだよな。
それがもったないからconst付けるんだ。 >>946
ところが chrar * 変数に対する初期化に文字列リテラル使うと>>936のようにエラーも警告も出さずにコンパイルが成功してリードオンリーの領域に書き込みアクセスするプログラムができてしまうと。 >>947
それはパソコンアプリ向けコンパイラが通常じゃROM化に対応してないからだよ。
昔からある話で、特別にROM化可能なコンパイル設定しないとな。 constつーか__attribute__((section(".rodata")))だろ >>932です。
みなさんありがとうございます。
C言語では文字列を扱うのは難しいようですね。
しかし使うだけであれば「なんとなく感覚的」に可能か?と思われます。
ところで、ネットや本でC言語の難所はポインタだ!とよく書いてますが、この文字列の部分というは正に
ややこしい部分ではないでしょうか?
ポインタと配列の関係性の理解だけでも一山あります。
それが文字列となると、ポインタ+配列+文字列の知識の理解、となってしまって。
構造体を勉強するのが先でしょうか。 >>950
この程度で難しいというなら、あきらめてJavaに行った方が身のためだ。
plain Cは時代遅れで、そのまま使うとセキュリティに穴があるシステムを量産してしまう。
Cはロボットにまかせて、人間はC++みたいな高度なプログラムを使うことが望ましい。 >>951
それを言うなら静かに自力で解決するやつ以外すべて足切り点未満だろ
plain Cで隙だらけのコードを量産するおまえさんが体現しているようにw >>951
最近プログラミングが騒がれているのでpythonを始めたのですが、どうもプログラミングしてる感
が持てないためC言語をかじりだしたのです。
javaはコードが長そうなので嫌な感じですね。C++はえらく難しいらしいですし...
まあpythonかrubyが普通に使えるくらいになれば十分なのですが... >>953
まずプログラミングしてる感が十分感じられるくらいまでpythonに慣れましょう 余所の芝が青く見えるので、そっちをつまみぐいする進め方は
正直どっちも中途半端に覚えてるつもりになって、実際には道具として使えてない状態に陥りそう >>953
C++ は教育的配慮に欠けていて、自力でなんとかしないといけない部分が多いし、ここ5〜6 年で規格がばたばた改定されたのに教科書が追いついていない
ついでに私もC++11later には追いつけていない(;;)
プログラムしている感は満載なんですけれども。
java は、資格とかもあり教育的な環境が整っているし書籍も多い、言語的な紛れもC++ に比べると少ない、個人的にはお勧めです。
プログラムしている感は、それなりにあると思います。
python 私もやっているんだけれども、つづりミスに悩まされています。なにか、いい支援環境はないものでしょうか? >>953
Pythonで何かをあやつることをやってみたら? GIMPや、Inkscapeや、IoTデバイスとかをあやつってみるんだよ。 Pythonは万能だから、株取引とか天気予報の表示とかニュースフィードとか、思い付く限りのことができるぜ。 >>959
地震の原因は、地球内部の核融合反応をエネルギー源とするマントル活動だから、三次元マントルマップを
作って天気予報みたいにスパコンでシミュレーションすればある程度予測可能なはず。 地下水で地盤ががたがたになったところを爆弾で引き金ひいてるだけだよ >>956
【Microsoft Tech Summit】APP017 PowerShellの新しい相棒 Visual Studio Code
http://www.youtube.com/watch?v=0zo6z0yHrGk
2017/01/23 に公開された動画 >>966
これかな?
https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E6%B2%88%E6%B2%A1
最近読んだので記憶は確かだが、細菌が地震の原因とは書かれていなかった
地球内マントルの対流の動きが変わり、ちょうど日本の真下でマントルが持ち上がるように変化した、という推測でストーリーは進んでいる そしたら探査船ちきゅうでぐぐれ
なんで非キリスト教国のまわりばっかり掘ろうとしてるんですかね レス数が950を超えています。1000を超えると書き込みができなくなります。