[B! c] rawwellのブックマーク

A Guide to Undefined Behavior in C and C++, Part 1 – Embedded in Academia

Also see Part 2 and Part 3. Programming languages typically make a distinction between normal program actions and erroneous actions. For Turing-complete languages we cannot reliably decide offline whether a program has the potential to execute an error; we have to just run it and see. In a safe programming language, errors are trapped as they happen. Java, for example, is largely safe via its exce

rawwell 2011/09/06

checkitout
c

リンク

IBM Documentation

rawwell 2011/07/20

"The postfix expression must be a pointer to an object of type class, struct or union"

c

リンク

Freeing after Malloc (The GNU C Library)

rawwell 2011/07/14

リンク

C言語の代表的なウェブリソース10選 - YAMDAS現更新履歴

Top 10 C Language resources that will turn you into a better programmer - C and C++ Programming Resources 今更 C 言語かと言われそうだが、Linux カーネルだって、我々が利用している LL 言語の多くだってこの言語で書かれているのである。ワタシ自身は未だどの言語よりCを愛している。以下に C 言語に関してウェブに公開されている代表的なリソースを挙げていく。さすがに更新が長らく止まっているものが多いが、それでも有用な情報源には違いない。ネタ元は Hacker News。 C Programming Notes Programming in C - UNIX System Calls and Subroutines using C. C Lesson by Chris Sawtell

rawwell 2011/06/07

checkitout
c

リンク

assertion プログラミングのすすめ - DOSEIの日記

assertion とは id:DOSEI:20041116:p1 に書いたとおり。次の定理が成り立つ。プログラムにバグがない ⇒ 全てのアサーションは真逆は成り立たないが、十分多くのテストがアサーションを真にするならば、プログラムにバグがある可能性を下げることができる。したがって、プログラムを改変していく過程で、常にアサーションを成り立たせるように努力すればよい。また、変更をするたびに、テストを増やすとよりよい。アサーションを使う上で注意すること。 assertion は実行時エラーを見つけるためのものではない。 assertion は、「仕様」をコード化する手法であり、「想定されるエラー状況」とは区別される。たとえば、「ファイルを開くことに失敗した」のがその関数で想定される状況であるなら、「バグ」ではないのだから、「ファイルは必ず開く」という assertion はできない。

rawwell 2009/07/13

"C 言語系で提供される assert() マクロ (in assert.h) は、 assertion が成り立たない場合に、その行と assertion 式を表示してアボートする。"

c

リンク

バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi

Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ

rawwell 2009/05/31

"MessagePackの特徴： * シリアライズ/デシリアライズがとても高速 * シリアライズされたデータのサイズが小さい * フォーマット定義（IDL）が不要 * ストリーム処理できる"

リンク

Executing scripts on a remote machine - Marigan's Weblog

rawwell 2009/05/27

"While technicall legaly, such behavior in memcpy() -- and the JNI operators that call memcpy() -- is, at best, surprising and violates the principle of least astonishment. Strictly speaking, memcpy() provides no particular guarantees about concurrently observable intermediate states, but rather onl

リンク

Debugging a segmentation fault using gdb

I am not a big proponent of gdb. If you *really* know what you are doing, gdb shouldn’t be required. But, every now and then, you come across code that has used function pointers exclusively and then, hand-debugging becomes painful. gdb to the rescue. You’ll need the following pre-requisites to use gdb to debug a segmentation fault: 1) make sure you have compiled the executable WITH debugging symb

rawwell 2009/05/25

"(gdb) bt (bt = backtrace .. prints stack strace) with this backtrace you’ll now know *exactly* where the program segfaulted. The code file, line number and the call which was the culprit. You can even analyze variable values on any frame. Just change to that frame: (gdb) frame {num} eg. (gdb) fra

checkitout
c

リンク

Python3.0 への移行準備 - methaneのブログ

http://coreblog.org/ats/why-python-30-is-still-deprecated 最も大きな理由。それはCで書かれたエクステンションの3.0対応がけっこう大変だから。 ... データベース接続モジュール，テンプレートエンジンとか，お世話になっているCエクステンションは多い。直接使って無くても，フレームワークがそういうエクステンションを使っていることが多い。その他にも，PILのようなライブラリ，wxPythonのようなGUIフレームワークラッパは修正点が多くて大変だと思う。これらのエクステンションの多くが3.0に対応してくれないと，僕は完全に3.0には移行できない。それまで数年かかるだろう，ということだ。まったく同感だったんだけど、最近はPython界が僕が思うより速く動いている事に驚いている。数年というのは3年以下かもしれない。 Pythonの「バージョ

rawwell 2009/04/06

boost.python C++の超有名ライブラリboostに含まれる、C++クラスのPython wrapper。 Google Summer of Code 2009 でPython3対応プロジェクトあり。

python3.0
c

リンク

char から int へのキャスト時の問題 - Cube Lilac

コメント - CLX C++ Libraries の動作確認への対応．コメントで，以下のソースコードでうまく encode/decode されないと言う指摘がありました（ソースコードは若干改変）． #include <iostream> #include <string> #include "clx/uri.h" int main() { std::string dest = clx::uri::encode("http://日本語.com"); std::cout << "encode: " << dest << std::endl; std::cout << "decode: " << clx::uri::decode(dest) << std::endl; return 0; } これを手元の環境（cygwin gcc 4.1.2, VC++ 8.0）で実行すると，以下のような結果

rawwell 2009/04/05

『元の文字が ASCII 文字コードに収まらない*1 ような値のときに int へキャストすると，符号拡張のため上位の領域がすべて 1 で埋められてしまうようです．』

リンク

ビットシフトの落とし穴 - 算術シフトと論理シフト - 職業としてのプログラミング

C言語には、ビットシフト演算子というものがあります。左シフト演算子(<<)と右シフト演算子(>>)です。同じビット演算でも、ビット単位の論理和(|)や論理積(&)、NOT(~)等はの方は、フラグ型の変数の処理で使われる事が多い気がしますが、ビットシフトの方は使用されるケースはあまりないかもしれません。さて、このビットシフト演算子で時々問題になるのが、符号ビットが立っている時の右シフト演算です。見逃されがちなポイントは、型によって挙動(算術シフトか論理シフトか)がかわることがある C言語の規格として、算術シフトか論理シフトかは不定 Nbitの算術シフトと2のN乗での除算は等価ではないといったところにあります。算術シフト(shift arithmetic)と論理シフト(shift logical:又は0充填シフト)という言葉をご存知ない方のためにちょっと説明を書いておくと、シフトによっ

rawwell 2009/04/05

『signedの場合は算術右シフト(sarl)命令、unsignedの場合は、論理右シフト命令(shrl)になっているのが確認できます。』

リンク

charの落とし穴 - 暗黙の型変換と符号拡張 - 職業としてのプログラミング

前回unsignedでよく陥りがちなバグについて触れました。今回はその続編で、char型での落とし穴として、いわゆる符号拡張(sign extension)と暗黙の型変換(inplicit conversion)について説明します。次のコードの問題点はわかるでしょうか？ typedef char value_t; #define INVALID 0xff /* valがINVALIDなら0、それ以外で1を返す */ int check(value_t val) { switch (val) { case INVALID: return 0; default: return 1; } 一見問題なさそうに思えますが、実際このコードをコンパイルして、valにINVALID(0xff)を指定しても1が帰ってきます。なぜでしょう？ C言語のswitch分では、比較値はint型として扱われます。よっ

rawwell 2009/04/05

『変換時には符号拡張が行われ0xff(charの-1)は0xffffffff(intの-1:intが32bitの場合)となってしまいます。よって、0xffとは一致しないのです』

リンク