(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
技術部の国分 (@k0kubun) です。 先日byebugの高速化を行っていた最中、変更を加えたbyebugを使っていると一定の確率でrubyがSEGVするバグを発見しました。 私はC言語のコードのデバッグの経験はなかったのですが、デバッガの使い方を調べながらSEGVの原因調査を行いパッチを送ったところ無事取り込まれ、最新の高速なbyebugが安全に使えるようになりました。 その際、ruby自体をデバッグするために必要な情報が分散していて大変だったので、まだrubyのデバッグをしたことがないけれどやってみたいという人を対象に、gdbというデバッガを使ったrubyのデバッグの方法を紹介します。 デバッグ用にrubyをビルドする デバッグ時に変数名やソースコードなどの情報を見るためには、最適化オプションをオフにしてデバッグ用にrubyをビルドしておく必要があります。 rubyのデバッグ用ビル
Unix v6 の C コンパイラをいじってみようと見てたのですが、これがなかなかすごい物体でした。 読んでて、「いやいくらなんでもこんな作りなわけが…」と思って説明文を探して、 http://plan9.bell-labs.com/7thEdMan/v7vol2b.pdf の「A Tour through the UNIX C Compiler」に説明あるよと教えてもらって読んでみたら、本当にそんな作りだった、みたいな。 コンパイラの1段目はプリプロセスして構文木的なものをファイルに吐いて終わりです。2段目は構文木を読みつつコード生成していく。 構文木のノードの種類に対して switch してやること決める…的なものが、データドリブンな方法で書かれてます。データを保存するフォーマットは、 JSON とかではなく、時代が時代ですのでアセンブリです。こういうやつ https://github
C言語の可変長引数は、型安全でない（まちがった型の引数を渡してもコンパイルエラーにならない）とされています。これは言語仕様の理解としては正しいのですが、特定の型の引数を任意の個数とる関数に限っては、マクロを使うことで型安全性を確保することができます。 任意の個数のdoubleを引数にとり、その和を返す関数「sumf」を例にあげて説明します。 C言語の可変長引数機構を使ってsumfを定義すると、以下のようになります。 #include <math.h> #include <stdarg.h> #include <stdio.h> static double sumf(double nfirst, ...) { double r = 0, n; va_list args; va_start(args, nfirst); for (n = nfirst; ! isnan(n); n = va_a
Cコンパイラといえばとてつもなく複雑なプログラムというイメージがあります。ところが、このCコンパイラを(サブセットとはいえ)わずか500行ほどのCのソースコードで実現した「CC500」名付けられたプログラムが公開されています。 ソースコードは可読性を維持するためにつけられた空行やコメントを含めると、実際は750行ほどになるそうですが、それでもこれだけコンパクトなソースコードで実行可能なELFバイナリ(Linux用のバイナリ)を生成できるのは興味深いのではないでしょうか。 以下実際にLinuxでコンパイルしてみました。 自己コンパイルできる このコンパイラはC言語のサブセットで、自分自身のソースコードをコンパイルできるところがおもしろいところです。まず「cc500_1」という実行ファイルを生成します。 gcc cc500.c -o cc500_1 生成された実行ファイル「cc500_1」を使
二十五日半狂乱、6日目(の分...orz)の記事 Cのエラーハンドリングを毎回やるのは面倒だ！ 前回も言ったが、Cではエラーハンドリングに戻り値とerrnoを用いる． それはそうと例外設計において"無視"は大罪である． だから、関数を呼び出したら戻り値は漏らさずチェックすべきだ． ということで、例えば以下のように逐一戻り値をチェックする． if(send(sockfd, buf, len, 0) < 0){ ERROR("send"); exit(1); } あぁ、面倒だ． 一体コードのどの部分が正常系の処理なのか？ ほとんどエラーハンドリング*1で埋め尽くされるじゃないか． そもそもエラーハンドリング部分に書くのは毎回同じコードだし、コードの繰り返しは防ぎたい． エラー処理部分をラッピングして楽をする unpv12eの中でラッパーを被せることによってこの面倒を回避する方法を知った． in
以前に8ccというCコンパイラをゼロからひとりで開発していたときのログです。40日でセルフコンパイルできるところまで到達しています。日付はすべて2012年です。コードとヒストリはすべてGitHubで見れます。 3月4日 というわけでコンパイラを作っているわけだけど、1000行くらい書いたらそれなりに動き始めてきた。こんなのも動くし： int a = 1; a + 2; // => 3 こういうのも通る。 int a = 61; int *b = &a; *b; // => 61 文字列は文字の配列として扱っていて、配列をポインタに成り下げる振る舞いも実装しているので、こういうのも通る。関数呼び出しもある。 char *c= "ab" + 1; printf("%c", *c); // => b 前回もこのあたりはがんばって実装したからここまで作るのはわりと単純作業かも。二回目だから配列とか
Kunihiko IMAI <bak＠d2.dion.ne.jp>2009 年 1 月 11 日 ARM gcc にまつわるいやらしい現象とその対策をまとめてみました． 1. はじめに 2. 責任の放棄 3. 想定している読者と環境 4. アラインメント 4.1 アラインメント条件を満たさないと 4.2 由緒正しい対策 4.3 バッドノウハウな対策 5. パディング 5.1 例 5.2 由緒正しい対策 5.3 バッドノウハウな対策 6. char 型 6.1 例 6.2 由緒正しい対策 6.3 バッドノウハウな対策 7. soft fp と hard fp 7.1 一般的な問題 7.2 ARM 固有の問題 8. EABI と legacy ABI 8.1 ABI とは 8.2 ABI の種類 8.3 違い 8.4 見分けかた 8.5 Debian での対応状況 8.6 影響と対策 8.7
何気なく呟いた言葉が確変状態になっていました。 それで、反応を眺めていると「何をやってるか分からない」と言うものがいくつかあったので、一応簡単な補足説明を載せておきます。 #include は指定したファイルの内容をその位置に追加します。 1, 2, 3, 4, 5, 6, 7, 8, 9,例えば、上記の内容を hoge.csv と言う名前で保存して、 int hoge[] = { #include "hoge.csv" }; と記述すると、（プリプロセスが終了すると）以下のように記述した事と同じになります*1。 int hoge[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, }; このように、#include を利用することによって、内容が変化しない*2データ配列などの定義を自力で打ち込んだりコピペしたりせずに済むようになります（なることがあります）。s/int/co
最近、kazuhoさんが作った「C」で遊んでいるのですが(いまごろかい！)、これWindowsでも使いたいなーなんて思ったのでポーティングしてみた。 C - a pseudo-interpreter of the C programming language Perl や Ruby では、ワンライナーで処理が書けて便利です。でも、なぜか C では書くことができません。仕事上の都合で、小さな処理を C 言語で書く必要があったので、ワンライナーも書くことのできる C 言語のインタプリタ(?)を作ってみました。 http://labs.cybozu.co.jp/blog/kazuho/archives/2006/01/large_c.php 目指せバイナリアン (C-0.06) C-0.06 をリリースします。 http://labs.cybozu.co.jp/blog/kazuho/archi
JTN002 - MinUnit -- a minimal unit testing framework for CIntroductionUnit testing frameworks are quite popular in the object-oriented programming world. Frameworks like JUnit (for Java), SUnit (for Smalltalk), and CppUnit (for C++) provide a rich set of functionality. However, this rich set of functionality can be intimidating to someone who wants to do unit testing in a more constrained environm
少し前のことですが，http://f.hatena.ne.jp/takehikom/20070121063702にスターをいただきました． 図ですが…少々古いです．昨年度の授業では，こうなっています． ただ，線が入り組んでいますので，PowerPointで表示するという制約を超えて，描き直したいものです…．Graphvizを使いましょう． http://homepage3.nifty.com/kaku-chan/graphviz/index.htmlをもとに，dotファイルを書きました． /* 2008.dot (途中版) */ digraph ckeyword2008 { 識別子 [style = filled, fillcolor = "#FF99CC"]; 算術型 [style = filled, fillcolor = "#FF99CC"]; 制御文 [style = filled
安藤のためのC言語テスティングフレームワークCUnit 『CUnit for Mr.Ando』は CppUnit-x をベースにしたC言語テスティングフレームワークです。 これは、C言語のソースコードを単体テストのために供給します。 "CUnit for Mr.Ando" is CppUnit-x based C langage testing framework for Mr.Ando. It provide the C source code for unit testing. イントロダクション Introduction. JUnit は非常に強力なJava単体テストツールです。 しかしながら、多くのC言語技術者はJava言語を理解することができません。 JUnit is a very powerful Java simple unit test tool. However, man
;;; google-c-style.el --- Google's C/C++ style for c-mode ;; Keywords: c, tools ;; google-c-style.el is Copyright (C) 2008 Google Inc. All Rights Reserved. ;; ;; It is free software; you can redistribute it and/or modify it under the ;; terms of either: ;; ;; a) the GNU General Public License as published by the Free Software ;; Foundation; either version 1, or (at your option) any later version,
標準規格 C言語 __DATE__ ソースのコンパイル日付 __FILE__ ソースのファイル名 __func__ 関数名（Visual Studio.NET以降では、__FUNCTION__） __LINE__ 行番号 __STDC__ 標準Cに従っている際に定義されている（ifdefで使う） __STDC_HOSTED__ 整数1 __STDC_IEC_559__ IEC60559浮動小数点仕様に従っている際に定義されている __STDC_IEC_559_COMPLEX__ IEC60559互換の複素数仕様に従っている際に定義されている __STDC_ISO_10646__ ？→http://seclan.dll.jp/c99d/c99d02.htm#dt19990412 __STDC_VERSION__ C言語のバージョン __TIME__ ソースのコンパイル時刻 __TIMESTA
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
