コメントの書き方(クラス・関数のコメント) このページの最新版は以下の場所をご覧くださいhttp://sakura-editor.wiki.sourceforge.net/DoxygenComment ソースコード中のコメントをdoxygenの 解説に反映させるためのコメントの書き方です。新規にコメントを入れる場合は以下のルールにできるだけ従うようにしてください。 関数内のコメントはこのルールに従っていただいても意味がありません ので通常のコメントで結構です。ドキュメント生成に関係するのは、 ファイル クラス メンバー関数(Inline含む) メンバー変数 グローバル変数 クラスのメンバーでない関数 定数宣言 (#define, enum) です。 doxygenで認識されるコメント スタイル doxygenではQtスタイル及びJavaDocスタイルのコメン トを認識します.コメントには要
ASKMEDIA Blog 弊社の情報を随時ブログで報告しています。youtubeやツイッターでも配信しております。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
<Home> → <My Glossary Index> → <Secure Programming 関連> この page は、開発者がより安全なコードを記載するにはどうしたらよいか、もしくはシステム側で防御するかについての手法について纏めています。 「ソフトウェア無謬性の神話」 [実践 Linuxセキュリティー(インプレス)] より。無謬性(むびゅうせい)とは過ちがないこと。 ソフトウェア開発に携わっていない人は特に「ソフトウェア(コンピューター)には誤りが無い」と錯覚している節があるようです。実際、医療や金融システム、航空宇宙分野ですらソフトウェアのバグにより被害を及ぼしています。 かなりの人月と予算を費やしたプロジェクトであったとしてもバグを防ぐことは出来なかったという現実を認識すべきです。 Buffer Overflow(Overrun) Buffer Overflow は、開発
Oct 2011 UPDATE: Frédéric Germain has setup a Github page containing all the below patches and additional new features, see: https://github.com/fredericgermain/LeakTracer. This is the newest version; all the below source code and documentation are of historic interest only. LeakTracer is a small tool I wrote when checking a C++ program for memory leaks. I couldn't get dmalloc to display what I wan
帰省、寿司、陶芸体験 8/13(火) 妻の実家の墓参りへ行き、俺の実家へ帰省。風呂に入る前に子供達と外で水鉄砲で水を掛け合いびしょ濡れになる。最後のほうはどうにでもなれと思い、ホースやバケツで直接水をかけ合う。久しぶりの大胆な遊び方に子供たちは大声をあげながら騒いでいるが、田…
10.4. ユーザ空間ではとりわけ秘密(パスワードや鍵)を守るアプリケーションがパスワードや非公開鍵(セッション鍵や秘密鍵)を扱う必要がある なら、公開を最小限にとどめるために、使用後はすぐに上書きしてください。 たとえば、Java では String 型にパスワードを保存しないでください。String 型は 変更されないからです(ガーベジコレクトされるか、再利用されない限り、上書き されません。こうなるには時間がかかるでしょう)。 String 型のかわりに、char[] を使ってパスワードを保存してください。そうすれば すぐに上書きされます。また、プログラムがそのような秘密の値を扱うなら、コアダンプを絶対作らないよう にしてください(ulimit を使って)。さもないと攻撃者がプログラムを中断させて、 ダンプしたデータから秘密の値を見つけ出すかもしれません。 もう 1 つ注意しなければ
この文書は、Linux および Unix システム上で安全なプログラムを書く際に必要と なる設計や実装について、そのガイドラインを提供します。 遠隔のデータを見るためのビューアーや Web アプリケーション(CGI スクリプト を含む)、ネットワーク・サーバ、setuid や setgid してあるプログラムが対象です。 C や C++、Java、Perl、PHP、Python、TCL、Ada95 個別のガイドラインも掲載します。 Table of Contents1. はじめに2. 背景2.1. Unix や Linux、オープンソースもしくは フリーソフトウェアについて2.2. セキュリティの原則2.3. なぜプログラマは危ないコードを書いてしまうのか2.4. オープンソースはセキュリティに効果があるのか2.5. 安全なプログラムの種類2.6. 疑い深く、こだわりが強いことに価値がある
Table of Contents5.1. C や C++ の危険なところ5.2. C と C++ でのライブラリによる解決策5.2.1. 標準 C ライブラリによる解決策5.2.2. 静的もしくは動的に確保したバッファ5.2.3. strlcpy と strlcat5.2.4. libmib5.2.5. C++ std::string クラス5.2.6. Libsafe5.2.7. その他のライブラリ5.3. C や C++ でのコンパイルによる解決5.4. その他の言語 頻繁に発生しているセキュリティ上の弱点は、「バッファオーバーフロー」 に対する脆弱性です。 バッファオーバーフローは「バッファオーバーラン」とも言われ、さまざまな バッファオーバーフロー攻撃が存在しています(「スタック領域破壊」や 「ヒープ領域破壊」もそうです)。 厳密に言えば、バッファオーバーフローはプログラムの実装
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く