C言語のbitfieldの仕様と実装を調査した話 - /home/tnishinaga/TechMEMO
C言語にはbitfieldという機能がありますが、この機能にはさまざまな落とし穴があり、注意深く利用しても予期せぬバグや移植性の問題を引き起こす可能性があるとよく言われています。 実際、jpcertを確認すると複数の勧告が出ています。 EXP11-C. ビットフィールド構造体のレイアウトについて勝手な想定をしない INT12-C. 式中で使用される単なるintのビットフィールドの型について勝手な想定をしない CON32-C. 複数スレッドによる隣接データへのアクセスが必要な場合データ競合を防止する DCL39-C. 信頼境界を越えて構造体を渡すとき情報漏えいしない 私は先輩技術者から「とくに組み込みの分野においてC言語のbitfieldは使うべきではない」と教わって生きてきました。 本記事ではbitfieldの仕様や問題点、なぜ仕様を避けるべきか、緩和策や代替案について検討します。 目次
プログラミングで「C言語」が難しいとされる理由は何ですか？
回答 (31件中の1件目) C の下にある仕組を知らずに覚えようとするから、難しいのだと思います。 私は、大学の専門課程の実験で 8bit の機械語を実体験した後、アセンブリ言語を経て C に到達しました。メモリのアドレスを意識しないと何もできない世界を知っていた訳です。 一方で、高級言語は Fortran (パンチカード!) から入りました。 そこから C に入ると、 1. 痒い所に手が届く (ポインタが扱える) 2. 算術演算子で 10 進計算ができる という不思議な言語に見えました。低級なんだか高級なんだか、わからない。 慣れてくると、ほとんどの高級な操作は標準関数を使っ...
The state of static analysis in the GCC 12 compiler | Red Hat Developer
Building a static analyzer into the C compiler offers several advantages over having a separate tool, because the analyzer can track what the compiler and assembler are doing intimately. As a Red Hat employee, I work on GCC, the GNU Compiler Collection. Our static analyzer is still experimental but is making big strides in interesting areas, including a taint mode and an understanding of assembly-
Are GCC and Clang parsers really handwritten?
It seems that GCC and LLVM-Clang are using handwritten recursive descent parsers, and not machine generated, Bison-Flex based, bottom up parsing. Could someone here please confirm that this is the case? And if so, why do mainstream compiler frameworks use handwritten parsers? Update : interesting blog on this topic here
Continuation based Cを試す - Qiita
Continuation based Cとは 以下、長いので略称のCbCと書きます。 状態遷移記述に向いたプログラミング言語 CbC の開発 C 言語における関数呼び出しやfor 文・while 文を排除し，状態遷移単位(code) での処理を記述できる言語の開発をしてます． https://ie.u-ryukyu.ac.jp/%E5%AD%A6%E7%A7%91%E7%B4%B9%E4%BB%8B/%E7%A0%94%E7%A9%B6%E5%AE%A4%E7%B4%B9%E4%BB%8B/%E4%B8%A6%E5%88%97%E7%A0%94%E7%A9%B6%E5%AE%A4%EF%BC%88%E6%B2%B3%E9%87%8E%E7%A0%94%EF%BC%89/ 詳しくはこの辺の論文を読むとよさそう http://www.ie.u-ryukyu.ac.jp/~kono/papers
64C/128Tの「Ryzen Threadripper 3990X」のパワーがLinuxでどこまで活きるか検証 (2/2)
Apache以外はどれもコア数が多い方が速く、特にRyzen Threadripper勢はLLVMやLinuxカーネルのビルドにおいて圧倒的に速い。ただ、Ryzen Threadripper 3990Xは速いことは確かだが、3970Xに対して圧倒的か、と言われると回答に苦しむ。gccのコンパイル時間ではそれが顕著だ。 ただ、巨大なソースから何度もビルドするような状況では、1秒でも早く待ち時間を短縮するためにRyzen Threadripper 3990Xという選択肢はありかもしれない。最も時間のかかる8C16TのRyzen 7 3800Xから乗り換えると仮定すると、12C24Tの3900Xに乗り換えるだけでジャンプアップが感じられるが、Ryzen Threadripper環境だと絶大な効果を得られるが、ビルドする対象によりジャンプアップ率は大きく変わるといったところだ。 最後におまけとして
KMC Staff Blog:GCC10の最適化によるmemsetでの無限ループの発生
2020年11月17日 GCC10の最適化によるmemsetでの無限ループの発生 以前、「GCCの最適化による予期せぬ無限ループの発生」という記事を書きました。この時は -fno-builtin-malloc や __asm __volatile("":::"memory"); などで対策できました。 しかし今回、現状最新の GCC 10 で、memset、しかもナイーブな *(char *)s++ = (char)c; みたいな実装ではなく、NetBSD の本格的な実装のもので発生し、-fno-builtin や -fno-builtin-memset、-ffreestanding などでも抑制できず、-fno-tree-loop-distribute-patterns というあまり一般的ではないオプションが必要になりました。 これは一見 GCC のオプションが効いてない、バグのように思
2020年8月26日 Linuxカーネル、約2500の"フォールスルー"をリプレース | gihyo.jp
Linus Torvaldsは8月24日（米国時間）、2020年10月のリリースに向けて開発中の「Linux 5.9」において、カーネルエンジニアのGustavo Silvaの修正パッチをマージした。このパッチではカーネル全体で使われていた2484もの「/* fall through */」および類似のコメント部分をすべて「fallthrough;」にリプレースしているほか、不要なfall-throughの削除も行われている。 Merge tag 'fallthrough-pseudo-keyword-5.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux -Linux kernel source tree Linuxカーネルのメインライン開発では、今回のパッチを提供したSilvaを中心に、s
x64 Assembly Language Programming
汎用レジスタが倍増したので引数の数が少ないときはスタック経由ではなく基本的にレジスタ経由になりました. また32bitのときにあった__fastcall, __stdcallなど(cf. VC++では)は全て無視されるようになりました. C++のメンバ関数の呼び出し方法についてはC++ではを参照. Cの関数のレジスタの使い方は次の通りです. レジスタの用途 レジスタ 用途 呼び出された側(callee)での保存の必要性 rax 戻り値 不要 rcx 1番目の整数型引数 不要 rdx 2番目の整数型引数 不要 r8 3番目の整数型引数 不要 r9 4番目の整数型引数 不要 r10, r11 - 不要 r12～r15, rdi, rsi, rbx, rbp, rsp - 変更するなら必要* xm0 1番目の浮動小数型引数 / 戻り値 不要 xm1 2番目の浮動小数型引数 不要 xm2 3番目の
Stack Smashing Protector - OSDev Wiki
/* Note how buffer overruns are undefined behavior and the compilers tend to optimize these checks away if you wrote them yourself, this only works robustly because the compiler did it itself. */ extern uintptr_t __stack_chk_guard; noreturn void __stack_chk_fail(void); void foo(const char* str) { uintptr_t canary = __stack_chk_guard; char buffer[16]; strcpy(buffer, str); if ( (canary = canary ^ __
KMC Staff Blog:GCCの最適化による予期せぬ無限ループの発生
2019年09月13日 GCCの最適化による予期せぬ無限ループの発生 コンパクトな独自の libc を実装していて、GCC のテストを通したところ、WARNING: program timed out. が原因による FAIL が多発しました。調べた結果、非常に意外な結果だったのでメモします。 問題は、calloc の実装でした。以下のように、全く問題無さそうな簡単なコードです。 #include <stdlib.h> #include <string.h> void *calloc(size_t n, size_t size) { size_t bytes = n * size; void *p = malloc(bytes); if (p) { memset(p, 0, bytes); } return p; } これが、GCC 6.4.0 の arm-eabi で O2 でコンパイル
printfに4285個アスタリスクをつけるとclang++が死ぬ - Qiita
def check(n) s = "*"*n f = open("test.cpp","w") f.puts <<EOS #include <cstdio> int main(){ (#{s}printf)("Hello World\\n"); } EOS f.close() return system("clang++ test.cpp") end check(ARGV[0].to_i) $ ruby check.rb 10000 clang: error: unable to execute command: Illegal instruction: 4 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 10.0.1 (clang
GCCの最適化 - Gentoo wiki
はじめに CFLAGS と CXXFLAGS とは？ CFLAGSとCXXFLAGSは、CやC++のソースコードをコンパイルするときに使われるオプションを、コンパイラに指示するために慣例的に使われる環境変数の一種です。これらの環境変数は標準化されているわけではありませんがそれに近い状況で用いられており、コンパイラを使う際に追加のオプションを指定したいなら理解しておく必要があります。GNU makeでは一般的によく使われている環境変数のリストが記されています。 Gentooシステムでは大多数のパッケージがCまたはC++で書かれているため、これらの環境変数はシステムがどのように構成されるかに多大な影響を及ぼします。そのため管理者にはこれらを正しく設定することが求められます。 これらはプログラムのデバッグメッセージの量を減らすために使われたり、エラーや警告のレベルを増加させたり、また、もちろん生
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Parsing the Linux kernel with Haskell: experience with Language.C
GCC - Game Lab -PukiWiki-
GitHub - rust-lang/rustc_codegen_gcc: libgccjit AOT codegen for rustc
How to compile 32-bit program on 64-bit gcc in C and C++ - GeeksforGeeks
GitHub - StanfordSNR/gg: The Stanford Builder
gccを使って、制御フローグラフを作成
GitHub - SL-RU/stm32-emacs: Some functions to automatize work with STM32 micro controllers in Emacs