タグ

cに関するy_rのブックマーク (43)

  • 闇のC++ Undefined Behaviorに対する防衛術 - Qiita

    はじめに この記事ではC++11以降を扱います。 適宜規格書を参照しますが、翻訳する暇がないのでしません。 英語がわからない場合、雰囲気で頑張ってください。 C++ MIX #1 で発表したことの焼き増しです。 恥ずかしながら、発表に派手にミスがあったので修正後のスライドを上げてます。 Undefined Behaviorと愉快な仲間たち Undefined Behaviorは長いので以降UBと略すことにする。 UBが起こるとどうなるか なんでもあり。 コンパイラがどんなコードを生成しても規格書上合法。 別にHDの中身を全部消すコードを吐き出しても問題ない、そんなことはありえないが。 UBが起こると、そのあとの挙動は一切不明で何が起こるか保証されない。 なので、UBは絶対に起こしてはならない。 何故か無限ループしているが、理由がわからなかったり。 いつの間にかかオブジェクトが死んでたり。

    闇のC++ Undefined Behaviorに対する防衛術 - Qiita
  • clang/gccに組み込まれたAddressSanitizer/LeakSanitizerでメモリエラーを捕捉する - 千里霧中

    C/C++でのユニットテストによるメモリリーク検出 - 千里霧中の補足。 メモリエラーの検出方法についてだけれど、最近のclangやgccだと、AddressSanitizerという動的解析ツールが組み込まれており、それを活用できる。 使用する場合はコンパイラオプション「-fsanitize=address」「-fsanitize=leak」等を指定する。 題材 例えば以下のコードを対象にする。 //main.c #include <stdio.h> #include <stdlib.h> void hoge(void) { int *a_buff = (int *)malloc(5 * sizeof(int)); a_buff[10] = 8; } int main(void) { printf("test\n"); hoge(); return 0; } これを普通にコンパイルして実行

    clang/gccに組み込まれたAddressSanitizer/LeakSanitizerでメモリエラーを捕捉する - 千里霧中
    y_r
    y_r 2019/04/03
  • AddressSanitizer

    Introduction AddressSanitizer (aka ASan) is a memory error detector for C/C++. It finds: Use after free (dangling pointer dereference) Heap buffer overflow Stack buffer overflow Global buffer overflow Use after return Use after scope Initialization order bugs Memory leaks This tool is very fast. The average slowdown of the instrumented program is ~2x (see AddressSanitizerPerformanceNumbers). The t

    AddressSanitizer
    y_r
    y_r 2019/04/03
    メモリデバッグのおともに / gcc 4.8 以降なら -fsanitize=address で使える模様
  • 低レイヤを知りたい人のための Cコンパイラ作成入門

    はじめに このオンラインブックは執筆中です。完成版ではありません。フィードバックフォーム このには一冊のに盛り込むにはやや欲張りな内容を詰め込みました。書では、C言語で書かれたソースコードをアセンブリ言語に変換するプログラム、つまりCコンパイラを作成します。コンパイラそのものもCを使って開発します。当面の目標はセルフホスト、すなわち自作コンパイラでそれ自身のソースコードをコンパイルできるようにすることです。 このでは、コンパイラの説明の難易度が急に上がりすぎないように、様々なトピックを書全体を通じて次第に掘り下げていくという形で説明することにしました。その理由は次のとおりです。 コンパイラは、構文解析、中間パス、コード生成といった複数のステージに概念的に分割することができます。よくある教科書的アプローチでは、それぞれのトピックについて章を立てて解説を行うことになりますが、そのよう

  • FIO19-C. ファイルサイズの計算に fseek() および ftell() を使用しない

    FIO19-C. ファイルサイズの計算に fseek() および ftell() を使用しない ファイルストリームを操作する関数を使用するときには、テキストモードとバイナリモードの違いを正しく理解することが重要である(レコメンデーション「FIO14-C. ファイルストリームにおけるテキストモードとバイナリモードの違いを理解する」も参照)。 C99 [ISO/IEC 9899:1999] のセクション 7.19.9.2 は、バイナリモードでバイナリファイルを開いた場合の fseek() の特定の動作について次のように述べている。 バイナリストリームでは、whence が SEEK_END の値をもつ fseek の呼出しを意味あるものとしてサポートする必要はない。 さらに、セクション 7.19.3 の脚注 234 には次のように記載されている。 バイナリストリーム(ナル文字の詰め物が可能なた

    FIO19-C. ファイルサイズの計算に fseek() および ftell() を使用しない
    y_r
    y_r 2018/12/07
    c++ ifstream は大丈夫かが気になる...
  • c2e01b17fa037460937f

    こんにちは。 最近はC言語で書かれたAndroid/iOS SDKのプロジェクトjoinしまして、ビルドや単体テストの自動化について色々試行錯誤しております。 最初はMakefileで色々頑張っていたのですが、前から試してみたかったninja-buildというビルドツールを使ってみて、意外と便利だったため共有します。 apple/swift のビルドにも使われていたので、CやC++の皆さんの間では有名なのかもしれませんね。オープンソースで、C++で実装されているようです。 https://ninja-build.org https://github.com/ninja-build/ninja *Windowsでも使えるようですが、この記事ではMacで動作確認しております。 homebrewでインストールできました。

    c2e01b17fa037460937f
    y_r
    y_r 2018/10/23
    ”差分ビルドが賢いninja-build”
  • 「pthreadサポート」の意味するところ - yohhoyの日記

    ある処理系が “POSIXスレッド(pthread)標準をサポートする” とき、処理系(実行環境を含む)で担保すべき事項と、利用者(アプリケーションプログラマ)が守るべき制約についてメモ。 アプリケーションをプログラマの意図通り実行させるための、処理系/利用者間の責任分解点は「メモリ同期(memory synchronization)」により定義される。 利用者:複数スレッドからの少なくともどれか1つが書込操作となる変数アクセスの場合、“メモリ同期関数” を用いた排他制御により変数アクセスが同時に生じないよう保証すること。 全てが読込操作である変数アクセスの場合、複数スレッドからの変数アクセスを同時に行ってもよい。(そのようなコードを書いても、意図通り実行されることが保証されている。) 処理系:コンパイル時に最適化を行う場合でも、あるスレッド内での変数アクセス操作を “メモリ同期関数” 呼

    「pthreadサポート」の意味するところ - yohhoyの日記
    y_r
    y_r 2018/06/28
    POSIX の規格により volatile 必要なし
  • Are mutex lock functions sufficient without volatile?

    y_r
    y_r 2018/06/28
    見解が分かれているが "pthred_mutex_xxx でメモリバリアがはられているので大丈夫" が正しいっぽい
  • Google グループ

    Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。

    y_r
    y_r 2018/06/28
    "Threads programming: do I need to use "volatile"?" / コンパイラが static 領域の変数の変更を見れないから volatile は必要ないという理由は弱い気がする。
  • DCL38-C. フレキシブル配列メンバには正しい構文を使用する

    DCL38-C. フレキシブル配列メンバには正しい構文を使用する フレキシブル配列メンバ(flexible array member)とは、2 つ以上の名前付きメンバをもつ構造体の最後のメンバが不完全配列型、つまり、構造体の中で配列のサイズが明確に指定されていない、特殊な型になっている配列を指す。struct hack と呼ばれるこの手法は広く使われており、さまざまなコンパイラが対応している。それゆえ、フレキシブル配列メンバの宣言にはさまざまな構文が使用されてきた。C 標準に適合した実装では、C 標準によって有効であると保証されている構文を使用すること。 フレキシブル配列メンバは、C 標準のセクション 6.7.2.1 パラグラフ 18 において次のように定義されている[ISO/IEC 9899:2011]。 特別な場合として、2 つ以上の名前付きメンバをもつ構造体の最後のメンバは、不完全配

    DCL38-C. フレキシブル配列メンバには正しい構文を使用する
    y_r
    y_r 2017/12/11
    構造体の最後のメンバのサイズ以上の領域を確保して、そのメンバを実質的に不定長配列として扱うのは未定義ではない。
  • ISO/IEC 9899:1999

    WG14/N1256 Committee Draft — Septermber 7, 2007 ISO/IEC 9899:TC3 Contents Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Normative references . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terms, definitions, and symbols . . . .

    y_r
    y_r 2017/12/11
    C の committee draft/WEB 上で簡単に参照する場合用
  • 2016年、C言語はどう書くべきか (後編) | POSTD

    (前編はこちら: 2016年、C言語はどう書くべきか (前編) ) (編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) システム依存の型 まだ「32 bitのプラットフォームでは32 bitのlong型、64 bitのプラットフォームでは64 bitのlong型がいい」という不満があるようですね。 プラットフォームに依存する2つの異なるサイズを使うため、 故意に コードを難しくすることを考えたくなければ、システム依存の型のために long を使おうとは思わないでしょう。 この状況では、プラットフォームのためにポインタ値を保持する整数型、 intptr_t を使うべきです。 モダン32-bitプラットフォームでは、 intptr_t は int32_t です。 モダン64-bitプラットフォームでは、 intptr_t は int64_t です。 int

    2016年、C言語はどう書くべきか (後編) | POSTD
  • 2016年、C言語はどう書くべきか (前編) | POSTD

    (訳注:2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注:著者のMattより、「文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例: 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり

    2016年、C言語はどう書くべきか (前編) | POSTD
  • alloca関数 - Qiita

    C言語で動的なサイズのメモリ確保が必要となれば、典型的にはmallocとfreeの出番ですが、allocaというものもあります。 C言語での変数の寿命 オブジェクト指向な言語の多くでは、ガベージコレクタが入っているので、「オブジェクトの寿命」≒「オブジェクトへの参照が存在する間」ということになります。これに対して、C言語(やC++)では、ガベージコレクタのような高度な仕組みはないので、変数の寿命は次の2つのどちらかになります。そして、C11で加わった可変長配列を別として、配列を確保するときもサイズは固定のしか取れません。 自動変数…スコープに入ったところで変数が用意され、スコープを抜けたところで解放される 静的変数・外部変数…プログラムの開始から終了まで存在し続ける これらに当てはまらない操作をしようと思えば、ライブラリ関数を使ってポインタ経由で使うほかありません。 allocaとは ふつ

    alloca関数 - Qiita
    y_r
    y_r 2017/05/21
    alloca 知らんかった...
  • 未定義の動作

    未定義の動作にはどのようなものがあるのでしょうか。C言語の標準規格であるJIS X 3010:2003(ISO/IEC 9899:1999)の「附属書J 可搬性」を参考に未定義の動作を列挙してみましょう。 規格の制約以外の箇所で現れる「…(し)なければならない」または「…(し)てはならない」という要求をプログラムが守っていない場合。(前提事項4) 空でないソースファイルが、改行文字で終了していない場合。改行文字で終了している場合で、その直前に逆斜線文字がある場合。ソースファイルが、前処理字句の途中または注釈の途中で終了している場合。(5.1.1.2) ##演算子による字句連結の結果として生成される文字の並びが国際文字名の構文規則に一致する場合。(5.1.1.2) ホスト環境のプログラムがmainという名前の関数を5.1.2.2.1で定められる4種類の方法のいずれかで定義しない場合。(5.1

    y_r
    y_r 2017/04/10
    C99 未定義動作一覧。
  • C言語分かってなかった (I Do Not Know C) - Qiita

    Dmitri Gribenko氏によるBlog記事 "I Do Not Know C" より訳出。原文および訳文のライセンスは CC BY-SA 3.0 に従う。 この記事の目的は、皆に(とくにCプログラマに)「C言語分かってなかった」と言わせることです。 C言語の死角は思っているよりも身近にあり、よくある単純なコードですら 未定義動作(undefined behavior) を含む可能性があると示したいと思います。 記事は質問に対する回答の形をとります。全ての例示コードは別々のファイルに分かれていると考えてください。 (訳注:Qiita/Markdown表現の制約から、読中ネタバレ防止のため文章順序を変更しています。前半には質問のみを、後半には質問と回答の対を訳出しました。) 質問編 1.

    C言語分かってなかった (I Do Not Know C) - Qiita
  • linuxカーネルで学ぶC言語のマクロ - Qiita

    はじめに 記事は電子書籍版もあります。 linuxカーネルはC言語のマクロを駆使して書かれています。それらのうち、凝ったマクロになじみの無い人には初見では意図がわからない&わかってみれば面白いであろうものをいくつか紹介いたします。対象読者は、C言語のユーザだけれども、マクロは定数定義くらいにしか使わないというライトなマクロユーザです。 マクロを使用する場所に依存するエラーを防ぐ 次のマクロは、二つの引き数の値を置換するだけの単純なものです。

    linuxカーネルで学ぶC言語のマクロ - Qiita
  • [Linux][C/C++] backtrace取得方法まとめ - Qiita

    __builtin_return_address() を使用する __builtin_return_address() を利用することで、callerのアドレスを取得できる。 引数の数値を増やすことで、更に上の呼び出し元を参照できる。 #include <stdio.h> #define __USE_GNU #include <dlfcn.h> void hoge() { Dl_info info; dladdr(__builtin_return_address(0), &info); fprintf(stderr, "%s : __builtin_return_address => %p\n", __func__, __builtin_return_address(0)); fprintf(stderr, "%s : Dl_info.dli_fname => %s\n", __func_

    [Linux][C/C++] backtrace取得方法まとめ - Qiita
  • 普通のやつらの下を行け: C でバックトレース表示 - bkブログ

    普通のやつらの下を行け: C でバックトレース表示 普通のやつらの下を行けの第2回として、今回は glibc の関数を使って C でバックトレース (スタックトレース) の表示を行ってみます。 バックトレースとは バックトレースとは、大ざっぱに言うと、現在の関数に至るまでの道筋です。たとえば、次の Ruby プログラムを実行すると、 1 / 0 の行で例外が発生して、バックトレースの表示とともにプログラムは異常終了します。 def foo 1 / 0 end def main foo end main この例では main から foo を呼び foo の中の 1 / 0 の部分で例外が発生しています。 % ruby divide-by-zero.rb divide-by-zero.rb:2:in `/': divided by 0 (ZeroDivisionError) from div

    y_r
    y_r 2017/02/16
    困った時の奥の手
  • C言語で可変長引数をそのまま別の関数に渡したい - Qiita

    #include <stdio.h> #include <stdarg.h> /* * printfした後改行する */ void printfl(const char *fmt, ...) { va_list list; va_start(list, fmt); vprintf(fmt, list); printf("\n"); va_end(list); } void main() { printfl("test:%d", 12345); // 12345 } C言語で可変長引数を使う場合は stdarg.h をインクルードしておく必要があります。 また、渡す先でva_listに対応している必要があります。 printf に va_list を渡しても正しく動作しなかったので vprintfを使っています。定義は以下の通り

    C言語で可変長引数をそのまま別の関数に渡したい - Qiita