昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
以下の文章は、Michael Feathers による On Loving C.. の日本語訳である。 文中の固有名詞などについて理解の助けとなるよう Wikipedia へのリンクを加えさせてもらった。 認めなければならないことがある。私は C を愛している。しばらくはそれを意識していても、忘れがちだ。Ruby、Haskell、OCaml、C++、Java、そして C# に心移りしたこともある――今も多くの言語に時間を割いているが、C の元に戻ってくると、私は故郷に帰ったような気持ちになる。 私は何十年も前に Kernighan と Ritchie の本をパラパラとめくったときのことを覚えている。C にはとても欲求不満を感じた記憶もあるが、とても満足を与えてくれたことも覚えている。C にはヘンなところがあるが、振り返ってみると、それは多くの他の言語のヘンさに比べれば不可解なところはずっと
LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #1/3 LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #2/3 LLVM Project Blog: What Every C Programmer Should Know About Undefined Behavior #3/3 コンパイラ基盤 LLVM のブログで、未定義の動作という C 言語のダークサイドについての記事が3回シリーズで公開されている。 C 言語で未定義の動作を実行したら、「鼻から悪魔が飛び出しても文句が言えない」というジョークは有名で……いや、そんなのを知ってるのは年寄りくらいか（参考：nasa
確かにCでしか書けない類のプログラムは存在する(例を挙げるならKernel)が、それはCの存在を赦す理由にはならない。確かにCに輪をかけてさらにダメな類のプログラミング言語は存在する(例を挙げるならC++)が、それはCの存在を赦す理由にはならない。確かにCでしか書けないダメプログラマは存在する(例を挙げてほしければここにおまえの名前を入れろ)が、それはCの存在を赦す理由にはならない。 そもそも計算機にできて算盤にできないことなど存在しない。存在しないんだぞ。なのに何故人はプログラムを書くのか。それはオートメーションのためなのであり、奴隷的使役から人類の尊厳を開放して、この地上に楽園を築くためである。まあそこまで大上段に振りかぶって普段から書いてる輩はいないにせよ、プログラミングとは楽をするため、豊かな人生を実現するため、誰かの幸福のために行うものだ。違うか?じゃあなぜプログラムを書くんだ?
C言語に初めて触ってから20年のロートルですが今まで知りませんでした。man fopen より。 The fopen() function opens the file whose name is the string pointed to by filename and associates a stream with it. ``a'' Open for writing. The file is created if it does not exist. The stream is positioned at the end of the file. Subsequent writes to the file will always end up at the then current end of file, irrespective of any intervening fseek
WhyINoLongerLikeOrUseCPlusPlus - もう C++ なんて好きでもないし使いもしない理由。 目次 この文書について もう C++ なんて好きでもないし使いもしない理由。 もう C++ なんて好きでもないし使いもしない理由。 この文書について "Why I No Longer Like or Use C++" の日本語訳です. http://prophipsi.blog-nospam-spot.com/2008/03/why-i-no-longer-like-or-use-c.html -nospam- は削除してください... 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 今日、 Artima に上がっていた C++ の記事を読んだ。右辺値参照(rvalue reference) という C++ の新機能について解説するものだ。頑張って読むうち
2009/01/29 東陽テクニカは1月28日、組み込みシステム開発向けのコンサルティングサービスを提供するエクスモーションと業務提携を結んだことを発表した。今回の提携で両社は、東陽テクニカが販売しているソースコード解析ツール「QAC」を活用したソフトウェア解析ツール「eXquto」を開発し、2月より販売する。 QACは、英Programming Researchが開発したディープフロー静的解析ツールだ。C言語で開発されたソースコードを解析してコーディングミスによるバグなどを見つけ出し、ソフトウェアの品質を「メトリクス」として指標化する。 eXqutoは、QACで測定したソフトウェアのメトリクスをまとめ上げ、ソースコードに含まれる問題を、グラフやチャートを用いたレポート形式で分かりやすく提示する。ソフトウェア構造やコーディング品質の善しあしを示す「スコープ別評価」と、ソフトウェアに潜む脆弱
C Codは、C、C++、またはObjective-Cコンパイラのフロントエンドとして、C言語をスクリプティング言語のように扱うことを可能とするものである。C Codには、C Server Pagesが付属している。C Server Pagesは、ウェブアプリケーションをCまたはC++で記述し、それをオンデマンドで自動的にコンパイルできるようにするために、CGIをサポートする。 Ubuntu、Fedora、openSUSE用のC Codパッケージは存在しない。今回は、64ビットのFedora 9マシン上でバージョン1.2.8のソースをビルドした。コンパイル中に小さな問題が生じたが、以下に示すように、CFLAGSにposition-independent code（PIC）のオプションを加えることにより解決することができた。PICコードは、メモリの別の場所にロードすることができるという利点が
Account Suspended This Account has been suspended. Contact your hosting provider for more information.
C コンパイラの中には、最適化処理において、ポインタ演算のオーバーフローチェックを行うコードブロックを省略することがあります。従って、こうしたコンパイラを使ってコンパイルしたアプリケーションは、バッファオーバーフローの影響を受ける可能性があります。 gcc 4.2 およびそれ以降のバージョンで本問題が確認されていますが、他のベンダが提供するコンパイラにも同様の問題が存在する可能性があります。 C 言語で次のような型が与えられたとき char *buf; int len; C コンパイラの中には buf+len >= buf が成立すると仮定するものが存在します。その結果、次に示すような長さチェックを行うコードがコンパイラの最適化によって省かれてしまうことがあります。 len = 1<<30; [...] if(buf+len < buf) /* 長さチェック */ [...オーバーフローに
C言語は、ポインタが使える言語です。ポインタを使えば、メモリの直接的な操作など、より柔軟なプログラミングが可能です。一方、そのためにはポインタがどのようなメモリ領域を指し示しているか、またポインタ自体が有効なアドレスを保持しているかなどについて十分な理解が必要です。 本稿では、C言語のポインタについて、配列との対比に焦点を当てて解説を行います。 ＊＊＊ C言語では、ポインタを配列のように扱うことができます。また、配列名はポインタに変換可能で、別のポインタに代入できます。 まずは1次元の場合について、ポインタと配列の関係を考えてみましょう。 宣言文の記述 いま、ポインタと配列を次のように宣言したとします。 char *p; ← char型へのポインタpを宣言 char a[5]; ← char型を要素とする、要素数5の配列aを宣言 この宣言の結果を図にすると、図1、図2のようになります。 図
これは、ちょっと これは、かなり 上記で話題になった記事ですけど、他のも覗いてみた。 C/C++のデータ型と書式を知る：入力の書式 #include <STDIO.H> .......... char a[11]; /* 半角10文字分の文字列を保持する変数(配列) */ scanf( "%s", a ); /* 変数aに文字列を入力 */ printf( "%s\n", a ); /* 変数aの値を出力 */ おい！ scanf って教える必要がある？教えるなら、fgets でしょう。 char buffer[11]; fgets(buffer, sizeof(buffer), stdin); printf("%s\n", buffer); 慣れている人ならば、sscanf も加えるかもね。 char buffer1[11]; char buffer2[11]; fgets(buffer
C/C++のポインタの機能--参照渡し（builder by ZDNet Japan）より： #include int main( void ) { int *n; *n = 5; /* ポインタ変数nに値5を代入 */ printf( "%d\n", *n ); /* ポインタ変数nが持つ値(5)の出力 */ return 0; } 難しい概念を、初学者にもわかるように簡単な概念で説明し、適度な知識が身についた後、改めて本来の概念を説明する。 そういう手法があることは、理解しています。でもね、これは、アカンやろう。 第一に、ポインタとはなんぞや。「一般の変数」との違いが説明されていない。その上で、次のページにはこんなことが書いてある。 先ほどまで*nと記述してきたポインタ変数は、宣言以降はnという記述も許される。これが用いられるのは、たとえばキーボードなどから値を入力するときである。その
目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1078 記事 - 2 コメント - 26210 トラックバック - 363 ニュース 著作とお薦めの品々は 著作とお薦めの品々は 東方熱帯林へ。 わんくま 東京勉強会#2 C++/CLI カクテル・レシピ 東京勉強会#3 template vs. generics 大阪勉強会#6 C++むかしばなし 東京勉強会#7 C++むかしばなし 東京勉強会#8 STL/CLRによるGeneric Programming TechEd 2007 @YOKOHAMA C++・C++/CLI・C# 適材適所 東京勉強会#14 Making of BOF 東京勉強会#15 状態遷移 名古屋勉強会#2 WinUnit - お気楽お手軽UnitTest CodeZine Cで実現する「ぷちオブジェクト指向」 CUnitによるテスト駆
ポインタとは ポインタはC/C++言語の特徴的な機能のひとつである。ポインタ（pointer）を直訳すると「指し示すもの」であり、別の変数や文字列定数の場所を指し示すために使う。また、ポインタを指すポインタ（ポインタへのポインタ）というものも存在する。 このページをお読みいただいている読者にあっては、「C言語 ポインタ」「C++ ポインタ」などのキーワードでWeb検索をしたことがあるかもしれない。そうするとポインタに特化した内容の書籍をいくつか見つけられる。それだけ奥が深い機能ということである。 ポインタの用途 では、ポインタはどんなところで使われているのだろう。C/C++言語では、あらかじめ定義されている関数が多数存在するが、その一覧には、*（アスタリスクあるいはアステリスク）が付いているものをよく見かける。 これらはポインタを表し、主に文字列の操作やファイルをはじめとするデータの入出力
strchr() ではまった話 標準Cライブラリに strchr() という関数があります。文字列の先頭から指定した文字を探すという単純な関数なのですが、先日、意外な仕様を知りました。 以下のコードを見てみます。 if (strchr("+-*/", c)) { // c は四則演算の記号かな? ... } この if 文は c が + - * / のいずれかの場合に条件が真となり、ブロック中が実行されます。…と、思いきや、実は条件が真になるケースがもうひとつありました。c が '\0' の場合です。 まさかと思って手元の Linux の man を見ると、文字列の終端のナル文字 ('\0') の扱いは明記されていません。 The strchr() function returns a pointer to the first occurrence of the character c i
はじめに CodeZineではお初にお目にかかります、επιστημη（エピステーメー）です。最初のアーティクルはクラシックなCのお話。 昨今のアプリケーションはオブジェクト指向言語による実装が主流と言ってもいいでしょう。C++、Java、VB.NETさらにはRubyやPythonといったスクリプト言語まで、オブジェクト指向でない言語を探すのに苦労するくらいです。 本記事では、今なお現役バリバリで活躍している手続き型言語の代表格（？）Cによる、オブジェクト指向のマネゴト（オブジェクト指向風味のCコーディングスタイル）を試みます。対象読者 もっぱらCを主な開発言語として使ってはいるけども、オブジェクト指向に興味と憧れを抱いている方。抽象データ型 手始めにオブジェクト指向の特徴の1つ、「抽象データ型（ADT：Abstract Data Type）」をCで実現してみます。抽象データ型とは、データ
「Why I hate C」という記事がありました。 私は個人的にはC言語が好きですが、C言語が嫌だという視点も面白いので要約してみました。 かなり削っているので詳細は原文をご覧下さい。 C言語は組み込みに使うには良い言語ですが、その他の99.9％のアプリケーションを作るには最適とは言えません。 現在、アセンブラが一般的なアプリケーションを書くための良い解では無いことは自明です。 ここでは、もはやC言語もそうでは無い理由を述べたいと思います。 C言語の最も大きな問題はプログラマが間違いを犯しやすい事です。 私も良く間違えます。 どんなプログラマであっても数千行のコードを書いてバグが一つも無いということはありません。 コード量が少ないということは間違いの数も少ないということになります。 C言語は、言語のデザイン上、より多くのコードを書く事を要求します。 また、新しく開発されたプログラミング言
ふと、 main = 195; とかやって喜んでいた私はバカだったんじゃないかと思いました。 Binary 2.0 などとうかれてほとんどバイナリのコードをゴルフに submit してたのはどうなのか、と。プログラムは ASCII で書くべきだったんじゃないでしょうかと。それもメンテナンスしやすいように、 isprint が true を返すような文字で書くべきではないのか、と。 とりあえず Hello, world! 書きました。そのままコピペでたぶん最近の x86 & linux & glibc なら動きます。それ以外の環境では無理です。 char main[]="`j X$@P[PYPPPPX4.4 PZUX, P^XH,=)F(P_X3F()8)8@)8@@)8)8@PYX@@@@CQBaGHello, world!\n"; int 0x80 とか ret とか ASCII の範囲
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く