サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
数学
pebble8888.hatenablog.com
メモリ破壊系バグとは メモリ破壊系バグとは、プログラマーが想定して割り当てたメモリ領域のサイズを超えた部分にデータを書き込んでしまい、 プログラムが意図通り動作しなくなるバグのことです。 このバグは以下の特徴を持っています。 再現性が100%ではない場合が多い。 バグの原因箇所の特定が難しい。 破壊するメモリの領域としては、スタック領域、ヒープ領域、その他があります。 また、プログラマが明示的に確保した領域またはライブラリが確保した領域に分けられます。 スタック領域の例としては、関数内で以下のように宣言した a[32] の32バイトなどです。 void hello(void){ char a[32]; memset(a, 0, 33); // 1バイト分オーバー! } このようにスタック領域を破壊した場合は、hello()関数の戻り先アドレスを上書きしてしまい、この関数以降は命令自体 まと
swiftでCoreAudioを使ってみます。 ラ(440Hz)のサイン波の音を再生するサンプルです。 import Foundation import AudioUnit import AudioToolbox import AVFoundation class MyAudioPlayer { var _audiounit: AudioUnit? = nil var _x: Float = 0 let _sampleRate:Double = 44100 init() { #if os(iOS) let subtype = kAudioUnitSubType_RemoteIO #else let subtype = kAudioUnitSubType_HALOutput #endif var acd = AudioComponentDescription(componentType: k
スタンフォード大学 Paul Hegarty先生のDeveloping iOS 8 Apps with SwiftでSwiftを勉強していますが、難解なところがあったので、自分でソースを書いてみました。 import Cocoa class MyObject { enum Op { case Function2((Double, Double) -> Double) case Function1((Double) -> Double) } func evaluate(op:Op, v1:Double, v2:Double) { var result:Double switch op { case .Function1(let f): result = f(v1) break; case .Function2(let f): result = f(v1, v2) break; } print
[2017-02-12 update] swift3からunsafeBitCastではなくUnmanagedを使う方法が推奨となっていますのでそちらをお使いください。 unsafeBitCastを使ってswiftのクラスをポインタとして扱い、コールバック後のクラスに戻して動作するかやってみた。 結論から言うと動いた。これでAppleのフレームワークのせいでObj-Cを書かなくてはいけないケースは無くなった。 swiftからコールバック関数を利用するC言語のSDKを使う場合、これは基本的なテクニックになりそうだ。 XXX-Bridging-Header.h #include "cfile.h" cfile.h typedef void (*CALLBACK)(void*, int); void registerCallback(CALLBACK callback, void* ref); v
Xcodeにはデフォルトでヒープ領域(mallocやnew)のアクセスオーバーランを 検知してくれる機能があります。 ただ、一発で検知してくれません。確実に検知する方法をここでは紹介します。 例えば、以下のようなヒープ領域をオーバーランするサンプルを使います。 - (IBAction)handlerA:(id)sender { // オーバーラン char* buffer = malloc(1024); memset(buffer, 0x0, 2048); free(buffer); } このメソッドを何回か実行すると以下のようなメッセージが表示されます。 1回ではなく何回かというところが重要です。 MemoryLeakBuster(55357,0x1f64a28) malloc: *** error for object 0xca53804: incorrect checksum for
gem install がやたら遅いので、何故こんなに重いんだろうと思ったら、 大抵はドキュメントのインストールで時間がかかっているようだ。 ドキュメントなんて要らねえ!ということで、なんとかする方法がないかと思ったらありました。 ~/.gemrcファイルを新規作成し、以下の内容を記載すればいいみたいです。 以後のgem installコマンド全てで --no-ri --no-rdocオプションが効くようになり、 無駄に時間がかからなくなります。やったー。 --- :update_sources: true :sources: - http://gems.rubyforge.org/ - http://gems.github.com/ :benchmark: false :bulk_threshold: 1000 :backtrace: false :versbose: true gem:
このページを最初にブックマークしてみませんか?
『pebble8888.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く