革命の日々！ __attribute__(alloc_size) を使わないと_FORTIFY_SOURCE を活かせないよ。という話
_FORTIFY_SOURCEというバッファーオーバーフロー攻撃を防ぐのにとても有用なマクロがある。 知らなかった人は以下のmanでもまず見てください http://linuxjm.sourceforge.jp/html/LDP_man-pages/man7/feature_test_macros.7.html _FORTIFY_SOURCE (glibc 2.3.4 以降) このマクロを定義すると、文字列やメモリの操作を行う様々な関数を 使用する際にバッファオーバーフローを検出するための軽めのチェックが 実行されるようになる。すべてのバッファオーバーフローが検出される わけではなく、あくまでよくある例についてだけである。 現在の実装では、以下の関数にチェックが追加されている: memcpy(3), mempcpy(3), memmove(3), memset(3), stpcpy(3),
卜部昌平のあまりreblogしないtumblr - 最速の memset64 を求めて 今回のお題は char 幅じゃなくて word 幅の...
今回のお題は char 幅じゃなくて word 幅の memset 、つまりプロトタイプだと void* memset64(void* destination, uint64_t image, int num_words); をどれだけ高速に行うかという話。なぜ高速化するかというと、塗りつぶす領域がけっこうでかいから。 候補 1: REP STOSvoid* memset64(void* d, uint64_t i, int n) { asm("cld; rep stosq;" :: "D"(d), "a"(i), "c"(n) : "memory"); return d; } 最近の CPU はクソ賢い。そのため、下手に手で loop unrolling するよりも、逆に CPU に「ここはループなんだぞおおお～」というのを明示的に指示してあげたほうが CPU 側が勝手かつ不気味に最適な
GCC 解読室 Wiki*
Wikiaへ引越し Wikiaへ引っ越す事になりました。 新しくページを作る時はWikiaの方にお願いします。 ▲ ▼ FrontPage GCC のソースコードをひらメソッドで読んでいこうかと思っています． GCC は，最も歴史が古く，よってたかって世界中の ｽｰﾊﾟﾊｶｰ に知恵と技術の限りを尽くして叩かれ続け，今では全てのフリーソフトウェアの礎石となっている，地球が宇宙に誇れるプログラム ((c) shinichiro_h さん ＆ wo さん) です．ぜひあなたも一緒に，この難攻不落の要塞に挑んでみませんか ? 私 (管理人 あろは) は，とりあえず今の所，フロントエンドが何をやっているのか (GCC の内部データ表現形式である木構造，GENERICTree と GIMPLE Tree がどのようにして生成されるのか) を理解したいです． (RTL を含む，ターゲットア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
